:D

Notes

{
  "query": " query GetAllBooks($q: String, $sort: String, $order: SortOrder, $page: Int, $perPage: Int)
    { books(
      q: $q,
      sort: $sort,
      order: $order,
      page: $page,
      perPage: $perPage
      )

    {
      id
      title
      author
      publishedYear
      genre
      }
    }",

  "variables": {
    "q": "harry potter",
    "sort": "title",
    "order": "asc",
    "page": 2,
    "perPage": 2
  }
}

Create

mutation CreateBook {
  createBook(input: {
    title: "The Great Gatsby",
    author: "F. Scott Fitzgerald",
    publishedYear: 1925,
    genre: "Classic",
    isbn: "9780743273565"
  }) {
    id
    title
    author
  }
}

Response

{
  "data": {
    "createBook": {
      "id": "101",
      "title": "The Great Gatsby",
      "author": "F. Scott Fitzgerald"
    }
  }
}

Read

query GetAllBooks {
  books {
    id
    title
    author
    publishedYear
    genre
  }
}

Response

{
  "data": {
    "books": [
      {
        "id": "101",
        "title": "The Great Gatsby",
        "author": "F. Scott Fitzgerald",
        "publishedYear": 1925,
        "genre": "Classic"
      },
      {
        "id": "102",
        "title": "The Catcher in the Rye",
        "author": "J. D. Salinger",
        "publishedYear": 1951,
        "genre": "Classic"
      }
    ]
  }
}

query GetBook {
  book(id: "123") {
    id
    title
    author
    publishedYear
    genre
    isbn
  }
}

Response

{
  "data": {
    "book": {
      "id": "123",
      "title": "The Great Gatsby",
      "author": "F. Scott Fitzgerald",
      "publishedYear": 1925,
      "genre": "Classic",
      "isbn": "9780743273565"
    }
  }
}

Update

mutation UpdateBook {
  updateBook(id: "123", input: {
    title: "The Great Gatsby (Special Edition)",
    genre: "Literary Classic"
  }) {
    id
    title
    genre
  }
}

Response

{
  "data": {
    "updateBook": {
      "id": "123",
      "title": "The Great Gatsby (Special Edition)",
      "genre": "Literary Classic"
    }
  }
}

Delete

mutation DeleteBook {
  deleteBook(id: "123") {
    id
    title
  }
}

Response

{
  "data": {
    "deleteBook": {
      "id": "123",
      "title": "The Great Gatsby (Special Edition)"
    }
  }
}

Search

Only supports paramter q for now.

query SearchBooks {
  books(q: "Gatsby") {
    id
    title
    author
  }
}

Response

{
  "data": {
    "books": [
      {
        "id": "101",
        "title": "The Great Gatsby",
        "author": "F. Scott Fitzgerald"
      },
      {
        "id": "102",
        "title": "The Waste Gatsby",
        "author": "J. D. Salinger"
      }
    ]
  }
}

Pagination

Only supports page and perPage for now.

query GetBooks {
  books(page: 1, perPage: 10) {
    id
    title
    author
  }
}

Response

{
  "data": {
    "books": [
      {
        "id": "101",
        "title": "The Great Gatsby",
        "author": "F. Scott Fitzgerald"
      },
      {
        "id": "102",
        "title": "The Catcher in the Rye",
        "author": "J. D. Salinger"
      }
    ]
  }
}

Filtering

query GetBooks {
  books(filters: {
    genre: "Classic",
    author: "F. Scott Fitzgerald"
  }) {
    id
    title
    author
    genre
  }
}

Response

{
  "data": {
    "books": [
      {
        "id": "101",
        "title": "The Great Gatsby",
        "author": "F. Scott Fitzgerald",
        "genre": "Classic"
      }
    ]
  }
}

Uravu is the object relationship intelligence engine yet to be developed for Injee. If done right, it will be the stepping stone for GraphQL, ORM classes export in various languages, and will enable Database Script export which will properly include foreign keys.

Injee was created to increase front end developers productivity massively, and it should also decrease the load on back end developers in the times ahead. Till today human needed to model a Database for CRUD app, no matter even if you use advanced frameworks like Ruby on Rails, Django etc. This is waste of time. We believe that a REST request too server, in a span of time holds enough information to model a database in a automated way. This is what we would like to develop in the near or far future depending on this cosmos makes us tick.

When modelling relationships between tables, there can be many types of relationships, this is how injee will detect it.

has one

A record can be related to another record in a way that it has only one relation with record in another table, and not anymore. This is called has one relation.

There is a table named citizens, and a citizen can have only one passport, so in injee it will be modelled as shown:

{
  "citizens": [{
    "id": "e9b3cd95-861e-414e-9417-c6267b51c222",
    "name": "Aravindan"
  }]
}

{
  "passports": [{
    "id": "......",
    "citizen_id": "e9b3cd95-861e-414e-9417-c6267b51c222",
    "number": "12345678"
  }]
}

There is a table passports, and a passport has a column named citizen_id that points to a citizen. Injee will scan for columns that has _id at its end, in this case its citizen_id, it will check if there is a table named citizen or citizens, if yes it will check if there is a citizen with id e9b3cd95-861e-414e-9417-c6267b51c222, if yes, injee will relate to it.

has many

In the ata structures below user has many owned books, one can model it as shown, where there is a table called users, and a user can have many books

{
  "users": [{
    "id": "e9b3cd95-861e-414e-9417-c6267b51c222",
    "name": "Aravindan"
  }]
}

{
  "books": [
    {
      "id": "......",
      "user_id": "e9b3cd95-861e-414e-9417-c6267b51c222",
      "title": "The Lord of the Rings"
    },
    
    {
      "id": "......",
      "user_id": "e9b3cd95-861e-414e-9417-c6267b51c222",
      "title": "The Hobbit"
    }
  ]
}

If you look at both the book records shown above, you can see that the user_id points to the same user. Injee will be smart to realize that this is a has many relationship. That is users has many books.

belongs to

A citizen can have a passport as shown:

{
  "citizens": [{
    "id": "e9b3cd95-861e-414e-9417-c6267b51c222",
    "name": "Aravindan"
  }]
}

{
  "passports": [{
    "id": "......",
    "citizen_id": "e9b3cd95-861e-414e-9417-c6267b51c222",
    "number": "12345678"
  }]
}

This means a passport belongs to a citizen, Injee will be smart enough to identify it.

has and belongs to many (habtm)

A book can have many authors, and an author can have many books, this is called has and belongs to many relation. It can be represented as follows.,

{
  "authors": [{
    "id": "aravindan_id",
    "name": "Aravindan"
  },
  {
    "id": "karthikeyan_id",
    "name": "Karthikeyan"
  }]
}

{
  "books": [{
    "id": "clojure_id",
    "title": "Clojure",
  },
  {
    "id": "python_id",
    "title": "Python",
  }]
}

{
  "authors_books": [{
    "author_id": "aravindan_id",
    "book_id": "python_id"
  },
  {
    "author_id": "karthikeyan_id",
    "book_id": "clojure_id"
  },
  {
    "author_id": "karthikeyan_id",
    "book_id": "python_id"
  }]
}

Look at the table authors_books above, it contains author_id and book_id. Injee should be smart enough to identify this is habtm. But, how we create this authors_books from CRUD interface or something? Should we hit POST /authors_books endpoint with data? For now maybe yes. Or what if we have hit POST /authors and POST /books endpoints with filed named book_id[] and author_id[]? The latter seems more elegant right?

Automatic model detection

So how does Injee detect a table is related to another table? One hint is, if the key is say user_id or users_id, and if there is table named users then Injee will detect it. But what if there is table named users, and user owns books, and if the key in books is owned_by_id, still Injee should detect it. Welcome to the magic of UUID.

{
  "users": [{
    "id": "e9b3cd95-861e-414e-9417-c6267b51c222",
    "name": "Aravindan"
  }]
}

{
  "books": [
    {
      "id": "......",
      "owned_by_id": "e9b3cd95-861e-414e-9417-c6267b51c222",
      "title": "The Lord of the Rings"
    },
    
    {
      "id": "......",
      "owned_by_id": "e9b3cd95-861e-414e-9417-c6267b51c222",
      "title": "The Hobbit"
    }
  ]
}

In the case above, Injee will check if there is a table named owned_by or it will try to pluralize it and see if there is a table in that name. If not, its UUID value is used. This could be expensive, but we believe that computers should work for us and no the other way around.

Polymorphism

Say you have a table named details with the following data:

{
  "details": [{
    "id": "e9b3cd95-861e-414e-9417-c6267b51c222",
    "name": "Aravindan",
    "description": "My name is Aravindan",
    "belongs_to_id": "user_aravindan_uuid"
  },
  {
    "id": "e9b3cd95-861e-414e-9417-c6267b51c222",
    "name": "Data Scientists",
    "description": "A group for Data Scientists",
    "belongs_to_id": "group_data_scientists_uuid"
  }]
}

belongs_to_id in the first record points to a record in users table, and in the second record, points to a record in groups table. Injee should be smart enough to detect it, and deduce that this is a polymorphic relationship.

Advantages

The advantage is that, the front end dev gets seamless experience. One is able to hit some URLs, and when one requires DB scripts to create databases, or ORM’s that needs to be generated in Python, Ruby or what ever language, those get generated seamlessly along with relations and foreign keys. If we implement GraphQL support in Injee, this uravu project will come handy for us. This should look like magic if we do our work right

Disadvantages

The disadvantage we fear is performance, let’s say that one has a gigabyte of data in memory, and we want to process it, may be the uravu engine will take time to process, maybe it could crash your system due to limited memory. We just don’t know. But we will give it a shot. We firmly believe in future fast volatile and slow permanent storage will blend to form fast permanent storage, then the equation for Databases will change and size of data will not matter much, even if it’s a lot.

Injee is an automated backend not meant for serious projects, it was created due to frustration of a backend developer who was forced to learn ReactJS. To learn it, he had to concentrate on ReactJS hard, for that the developer should not think about the backend, it’s for that Injee was created.

Injee is great for learners, and it’s great for POC. Maybe it will get better, maybe not. So authentication in Injee might not be super professional. This document will describe how.

How it will work

So you are a designer / front end dev, you have designed a page like this.

Once the user clicks login, ask for username, and password; or email, and password. Say the user credentials are stored in table users, give a POST hit as shown:

POST /auth/:table/login

You can pass the these parameters in the hit:

{
  "username": "......",
  "password": "......"
}

It could also be email and password as shown. Pass them as body params.

{
  "email": "......",
  "password": "......"
}

Once successful login, the response will be as shown:

{
  "token": "slkdgslkjg3284923rsdfjsdfj"
}

This token will be accoumpanied by HTTP status 200. Else with status 401 unauthorized, you will get a message as shown:

{
  "message": "Invalid username or password"
}

To get user details, one needs to hit a URL like this:

GET /auth/:table/current

Along with the auth token which was returned on successful login. You might get the user details as shown:

{
  "username": "......",
  "first_name": "......",
  "last_name": "......",
  "email": "......",
  ....
}

Once logged in you might change the UI top reflect a user icon.

When clicked it might goto users page, which displays user details.

Jekyll requires blog post files to be named according to the following format:

YEAR-MONTH-DAY-title.MARKUP

Where YEAR is a four-digit number, MONTH and DAY are both two-digit numbers, and MARKUP is the file extension representing the format used in the file. After that, include the necessary front matter. Take a look at the source for this post to get an idea about how it works.

Jekyll also offers powerful support for code snippets:

def print_hi(name)
  puts "Hi, #{name}"
end
print_hi('Tom')
#=> prints 'Hi, Tom' to STDOUT.

Check out the Jekyll docs for more info on how to get the most out of Jekyll. File all bugs/feature requests at Jekyll’s GitHub repo. If you have questions, you can ask them on Jekyll Talk.

Deleting Table

Let’s say that you want delete a table, this is how you do it currently:

$ curl -X DELETE http://localhost:4125/api/delete-table/users

We get a message as shown below, informing us that the table has been deleted:

{
  "message": "deleted table users"
}

From now on the api above will be replaced with ops, and status returned will be 204. So the new api will be like this:

$ curl -X DELETE http://localhost:4125/ops/delete-table/users    

Listing Tables

Currently this is how one lists tables:

$ curl -X GET http://localhost:4125/ops/tables

Output

[
  "books",
  "users"
]

From 1.0.0, this is what will be returned:

{
  "tables": [
    "books",
    "users"
  ]
}

If you are following Injee, you know that we want to build an admin UI for Injee so that UI/UX people don’t have to use command line to administer Injee. We prefer to use HTMX as it requires less development effort than other JavaScript frameworks, the above returned will enable us to embed it properly using mustache.

That’s it!

That’s it for now. Until the next Injee update, bye bye!!

Injee’s success has been swift, thanks to rock solid programming language Clojure we were was able to achieve it. Though Injee has got success upon success, we know that this could bring complacency and failure as we are drowned in the dope of success. Though there are features that need to be implemented Injee, we are announcing a feature freeze till February 2025. During this time we will be looking at Injee’s code, reviewing it, perfecting it, and testing it, improving the documentation..

This will ensure Injee’s code is agile and is able to respond to changes as and when necessary. Injee is created by Clojure learners, and not experts, we have used ring which is new to us. We need to upgrade our knowledge in those domains too and implement our learnings in Injee.

What we wish to achieve is to have a rock solid codebase for Injee, with which we can develop new features. We hope Injee brings happiness to your life.

Every backend framework creator does get a excited while seeing how sexy HTMX is, as a creator of injee, I am no different. I have been thinking about how to make injee work with HTMX.

JavaScript frameworks are good to people only who know JavaScript, but for a person who knows programming they suck. So its natural that any backend creator does want to support HTMX.

There are my ideas for Injex = Injee + HTMX.

Defining views

Views in injee are just normal text file, say you want to display a content about user, then in the place where injee runs, define a file called /views/users/display.html, now say that file has the following content:

<h1> {{ user.name }} </h1>
<h2> {{ user.profession }} </h2>

Calling views from views

Now when you call /views/:table/:view, that is http://localhost:4125/views/users/CRDT-Y7-HQ/display.html, then, the user ones values:

{
 id: CRDT-Y7-HQ
 name: John Doe
 profession: Software Engineer
}

Then the returned HTML would be:

<h1> John Doe </h1>
<h2> Software Engineer </h2>

Calling views for all records

One can call views for all records using URL like this: http://localhost:4125/views/users/all/display.html. In this special case, one can paginate, search and so on.

CRUD

Of course you might need some views to be returned when you CRUD, right now I am not sure how to do it. But if I get the idea, I will write about it.

So let’s start our injee:

$ curl -L https://yu7.in/run-injee | sh

Now let’s create a user:

$ curl -X POST http://localhost:4125/api/users \
       -H "Content-Type: application/json" \
       -d '{"name": "Aravindan", "country": "Sri Lanka"}'

So we get a confirmation of the creation:

{
  "name": "Aravindan",
  "country": "Sri Lanka",
  "created_at": "2024-08-21T15:04:25Z",
  "updated_at": "2024-08-21T15:04:25Z",
  "id": "a65cf235-2a0e-4ca2-9114-79fb3722184d"
}

Now let’s create a book:

$ curl -X POST http://localhost:4125/api/books \
       -H "Content-Type: application/json" \
       -d '{"title": "Adventures of Huckleberry Finn", "author": "Mark Twain"}'

As we see below it’s created successfully:

{
  "title": "Adventures of Huckleberry Finn",
  "author": "Mark Twain",
  "created_at": "2024-08-21T15:04:32Z",
  "updated_at": "2024-08-21T15:04:32Z",
  "id": "8f0df4e3-bc34-4dd2-a979-39469168bf10"
}

Let’s list tables:

$ curl -X GET http://localhost:4125/ops/tables

As we see below there are two tables, users and books:

[
  "users",
  "books"
]

Now let’s delete the table users:

$ curl -X DELETE http://localhost:4125/api/delete-table/users

We get a message as shown below, informing us that the table has been deleted:

{
  "message": "deleted table users"
}

Now let’s list tables:

$ curl -X GET http://localhost:4125/ops/tables

As you can see below, we don’t see users table anymore.

[
  "books"
]

In the terminal where injee is started, hit CTRL+C to stop it.