From the database schema to RESTful API with DinGo

In the previous post I had started writing about data model and code generation and the post coincided with the boot of an open source project called DinGo thought to generate the Go code for a Microservice host analysing the schema of a relational database.

It's a very SQL First approach to write code, so I don't think it should be good for all the projects, but surely there are many applications that can take advantage from this, at least those are using already defined relational databases and want to adopt a Microservice architecture and RESTful API.

What DinGo does

DinGo creates a Microservice application starting from a MySQL database schema. Dingo follows these steps during the generation process:

1. DinGo reads the information_schema of the MySQL database
2. it generates a set of Data Model structs used to map tables into Go structs
3. it generates the Data Access Objects, these objects provide a set of basic operations (CRUD operations) necessary to manipulate entities
4. it generates the View Model structs that are similar to Data Model structs but don't depend on sql package
5. it generates Business Objects that are wrapper around the DAO objects
6. it generates Service Objects used to expose web methods
7. it creates the host server Web App
8. it writes the JSON configuration file necessary to the Web App
9. it writes the custom endpoints file used to extend the Web App endpoints

The result you get is a web API application that you just compile and run.

Architecture of the Web App

The application is composed of three layers

• the exposure layer is formed by the Service Objects and contains the web methods
• the business layer provides Business Objects and contains the business logic
• the data layer that provides DAO components and is responsible for database accesses

View Model it is used by the REST API that receive and transmit data in JSON format.
Data Model is used to communicate with the DAO components and maps tables and views of the database.

How DinGo works

After reading the information about the database schema, DinGo creates the structures that contain all the information necessary to produce the Go packages that will be generated.
The information associated with packages concern the list of the structs contained in them, the methods to be included and the imports necessary to the compilation.
The information is then passed to the file generators that process the Go code templates. All templates are included in the DinGo project and they allow the creation of the Web App. 

If necessary, the templates can be modified according to the developer's requirements, just make a fork of the Dingo project on GitHub.

What DinGo produces

The generated Web App has a structure similar to this example

The project's structure respects the architecture of the application design.

The main application depends on the service package that depends on the biz package that depends on the dao package.

There is also a config.json file that contains all connection parameters, so when the application is running, it can query the database that originated all the code.

It is not mandatory to generate all the application layers, you can control which layer DinGo have to produce by setting the configuration properties SkipDaoGeneration, SkipBizGeneraion and SkipServiceGeneration.

How to customize generated code

All the objects generated by DinGo can be extended by adding custom methods, it's recommended that the new methods are going to be placed in new files, so there isn't the risk of overwriting them by running DinGo again.

There's a special file named customresurces.go that can be used to add new endpoints to the REST API, this file is created only one time and never overwritten and it contains a method that is called at startup.

All the API are exposed using Gin-Gonic, but if you want you can use another web framework. You can produce only the DAO and the Biz layers then you are allowed to use any other framework for the Web App, but in that case you have to develope the exposure layer yourself.

DAO and Biz components can be used also in batch applications that don't need to expose web methods.

Conclusions

DinGo quickly produces code that we should achieve alone and that is often the most repetitive part in the creation of REST API services.
But all that DinGo does is just a starting point of our Web App and then it's up to us to complete the application and comply with the requirements.