If you are building an app or thinking of building on in the future. The most important things you need is a backend. The backend that stores your data and talks to your app. Getting it right is critical. If you don't. You will end up spending most of your time getting it right.
If you have already built an app or two. You already know the cycle. The cycle to make even the smallest change.
- Change the code on the server
- Save the changes and deploy the changes on the server and wait.
- Test if the API is sending out the just the right information
- Test the App for WYSIWYG
What If I told you. There's an App on the market.
What If I told you. There's an App on the market. No, it's right here. And it's called Metamug.
It focuses is on building the product faster, more reliable, dynamic, high performance and secure.
Setting up and installing Metamug API Console:
- Unzip and add values to a config file and ready to go, as opposed to installing MVC frameworks (Django, Rails, CodeIgnitor, CakePHP, Slim, Laravel, Zend, Yii).
API Development Approach
- REST resource-oriented approach makes it easy to design and create the APIs as there is no need to design and maintain complex routing architecture using code. Metamug forces the developer to use the correct REST standards.
- Uses XML files for defining REST resources which allows "Hot Deployment" of APIs and changes can be reflected quickly (change your API in 200ms).
- Encourages use of PL/SQL which is fast and easy to use (The 4th gen lang).
- Developers end up using pure SQL inside MVC anyways as ORMs provided by MVCs are not efficient.
Performance
- Lack of need of writing API development code coupled with writing data-processing logic in PL/SQL makes the system, very fast as compared to using MVC frameworks (whose code creates a large overhead, Python/PHP are already slow, the MVC frameworks have their own ORMs (even slower!!!)).
- The entire framework runs on Java making the overhead of the framework code very less, as Java intermediate code runs a lot faster than any other language except C/C++.
Business Logic
- Provides containers (processable interfaces) where Java code can be directly written without the fuss of installing and configuring Java environments.
- Maven support allows the user to access the vast range of Java libraries, so there's nothing that the system cannot execute (Java has the largest number of libraries available If you can do it in some language bet you can do it in Java!).
Minimalism saves time
- Metamug handles all the common tasks (creation of API endpoints, request parameter validation, processable interfaces) for you. (Don't repeat yourself). This as opposed to installing MVC frameworks and then writing all the code inside the boilerplate provided by the framework itself (then why use the MVC framework in the first place?).
- Focus on your data and client-side UI, leave the rest (pun intended) to us.
API Doc Generation
- Metamug will automatically generate API docs, no need to search elsewhere. You don't need any swag here. We keep it clean and more simple. Your pointy-haired boss can also read the API doc.
Analytics
- No need to use 3rd party API analysis tools. Metamug tells you how your REST API is being called from the apps. Check the homepage
Why metamug won't let you define URI?
Mapping path to a function
There are many libraries out there, which maps a function to the path. REST is designed to use URI as the resource identifier, as the name suggests. According to REST, each URI should represent a unique resource. This resource should be considered an object.
Using path as verbs
Developers often name the URI (in systems they are allowed to) according to the function being performed. For, example /api/users/getUserData is created inside the resource and mapped to a function that is supposed to retrieve user data. Now as the application grows, such URLs grow in number and there is no structure to manage it and it becomes cumbersome.
Imperative or declarative URI
Metamug API server doesn't allow the developers to define the URL. The user is not even allowed to add the version number in the URI. The resource file, its version, and backend are together used to form the URI. This makes sense since this comes with consistency and a structured approach for building scalable APIs.
As soon as a resource file is deleted the resource is unavailable. So the developer is not declaring the URL at any point the system. Thus, relieving him from managing it.
Resource Nesting
Now, as the developer starts to follow this imperative approach. He can now visualize the resources as a group of objects that can be related as well to retrieve some information. Hence, resource nesting is born. Resource nesting allows the developers to connect two or more resources with (HAS-A) relationship. Identifying these relationships can greatly ease the development. Here's an example.
