One of the complex parts of application development is to first write code to connect to your database and trying to leverage an Object Relational Mapping (ORM) framework to help write your data access layer.
But what would things look like if you didn't need an ORM? Or didn't need to write data access code to access your database? How would you then expose the data AND access it safely for your frontend application development?
REST API's provide a standardized interface to use HTTP requests to return data to users or applications in the form of JSON, HTML, XML, etc.
We can use some middleware to sit between our database and our application. We can then use RESTful queries in our application to ask the middleware to give us the specific data filtered to our liking as needed for our applications' operations. But which middleware? And wouldn't something in the middle slow things down?
DB2Rest is open source middleware that offers a no-code way to safely expose data from your database for your applications to consume. It's runs as a service that you can host locally or in the cloud. It even has an easy to use Docker deployment.
Simple
Let's see a simple example of a query with DB2Rest that shows how to filter on our database table of movies.
QUERY:
http GET 'http://example.com/movies?filter=title=="Titanic";year=gt=1950' \
User-Agent:insomnia/8.6.1
RESULT:
HTTP/1.1 200
Content-Type: application/json
Transfer-Encoding: chunked
[
{
"title": "Titanic",
"year": 1953,
"distributor": "20th Century Fox",
"budget": "$1,805,000",
"director": "Jean Negulesco"
},
{
"title": "Titanic",
"year": 1997,
"distributor": "Paramount Pictures",
"budget": "$200,000,000",
"director": "James Cameron"
}
]
Notice the QUERY where we didn't even need to use a full SQL query!?! We simply asked to filter the year greater than (=gt=) 1950 and it easily returned results! DB2Rest uses simple syntax (based on RQL) for querying and even joining tables.
Fast
DB2Rest is blazing fast even as middleware and reported by users since it doesn't need to use an ORM, but instead uses industry proven data access libraries and drivers for the most common databases. The queries are even cached for greater speed. DB2Rest translates your queries (without code generation!) into SQL so you don't have to, forwards to the database, and returns paginated results in JSON. If you already know SQL, DB2Rest can also just forward any custom SQL expressions to your database.
This is really great, because with DB2Rest you can even expose legacy databases to your applications without all the pain of coding, and quickly take advantage of that older data, or even skip database migrations and just use DB2Rest to give data access to your legacy data!
Secure
What is even better, I think, is that DB2Rest can serve as a gateway of sorts by being middleware and not directly exposing your database to your application, but instead only the data it needs. There's not even a possibility of SQL Injection attacks because of this. Security concerns are further minimized by configuring DB2Rest to use a DB user account that only has access to the schema and tables you wish to give access to. All data access security is thus handled directly by your database user access roles (and not DB2Rest) to conform with best practices and allow database administrators (DBAs) to continue to maintain security access roles as they need, even in an enterprise setting.
Visit DB2Rest.com to learn more and see all the databases it currently supports and other examples of advanced filtering, updating, deleting, and joining data from tables.
Top comments (3)
Looks interesting and can save a ton of work! I wonder if this was pen-tested before and is enterprise ready.
Users are using it in the enterprise, please feel free to join Discord with other users to help provide valuable feedback.
Also, authentication and authorization development is in progress and will be available late June24.
Has not been "fully" audited. But we welcome anyone or organization to do so! Data leakage would be at most risk with DB2Rest where mitigation would be ensuring your configured db user account(s) have the right roles and intended restricted access to the tables/views you want exposed to the world/users/applications.