Node.js APIs and load

[#1]

My team is currently working on a way to quickly mock up a large number of APIs (>50) for use in proof of concept type applications. We want to be able to build these using only a JSON file containing data in the correct structure as input. We are planning to use json-server (https://github.com/typicode/json-server) and push a simple server out to Edge. After we will use a script we wrote to generate the documentation.

As these APIs would begin being hit we are curious whether there will be any load issues with a potentially large number of node servers being spun up all at once. Could this approach be taken to production?

Can anyone validate this approach or if it won't work suggest another one?

[Former Community Member]

@schofa11

Why don't you use BaaS?

[#3]

I'm still somewhat new to the platform so it was more I already know node and it took me no time to have json-server up and running locally.

Part of the goal of these mock APIs will be to get other developers used to accessing a dev portal to 'shop' for APIs to use in their apps. Can I still do that in BaaS?

[#4]

Hi @Andy S, json-server is pretty cool! I can see a few use cases for developers. I've tried a few of frameworks out there to generate mock APIs, so I'd provide this post with some recommendations for your consideration:

• If you and your team already decided that json-server and the REST style that it implements is the way to go, try it by all means on Apigee Edge (full disclosure, I haven't tested it on Edge) and make sure it meets all your corner cases. In the past and for other Apigeeks, I recall building APIs based on DSLs that are pretty opinionated, you can hit a wall down the road and it's hard to go back. I see that json-server supports custom routes. So, that might be an option for you. If you want to try other frameworks such as Nock.js framework, which I highly recommend, check out this article: How to Build a Node.js API Proxy with Mocks
• You're right about performance. Depending on the scope of your project and the structure of you API team or teams. You might want to consider breaking up the monolith API mock into multiple microservice-oriented API mocks. Definitely, there are pros and cons for microservice-oriented API mocks. Some pros, easier control, management, and isolation. Downsides, applying changes to all mock APIs may become a major undertake. However, with the help of NPM modules and build tools. You may want to consider leveraging build frameworks such as Apigee Grunt or Maven to build and manage your mocks in a consistent manner. All in all, these days I generally recommend to take the microservice approach.
• Can you use this approach in production? No one is stopping you from using the monolith API approach. However, I hope aforementioned pros may make you consider breaking up the monolith into more manageable pieces. However, at the end of the day, the team decides what approach adapts to the business at hand.

Hope it helps!

[#5]

I went back through some of your code on GitHub using Nock and there are definitely a ton of options and features that come with it, I'm going to look into it more.

I think we will likely continue down the json-server path for the type of mocks we are looking to build because of the timeline we're trying to get them done by. Then as we have a little more time, look into other approaches.

[DChiesa]

Are you modelling the APIs? If you write an OpenAPI spec, then you can get mocking for free.

See apistudio.io