Is it only me that mocking server API is sooo hard?
Is it only me? Tried a bunch of services but oh man, setup and mock server API for my mobile app is soooo hard.
Is it only me? Tried a bunch of services but oh man, setup and mock server API for my mobile app is soooo hard.
I haven't used an online service for this, but I write a lot of server APIs for mobile games. It helps to think of the server call as "just an async function that takes type A and returns type B." Your client's ServerConnection is just a class that implements all of those functions.
You can easily write a version of ServerConnection that returns local data instead of making network calls, and then later replace it with the real version that talks to the server.
If your backend is written in the same language, you now have the blueprint for the backend service too; you know exactly what methods it has to implement. You just need some boilerplate around it to turn JSON -> type A -> run f(A) -> type B -> return JSON.
If you're using a different language it would be nicer to have the API defined in a language-agnostic way; it's always possible to create that language-agnostic spec from your code that defines the interface/types.
All the main languages that I know off have libraries to mock API data. Usually the problem is bad API design.
I know Microsoft gets flack in HN, but I find this document a pretty good primer on API design and decisions you should make: https://docs.microsoft.com/en-us/azure/architecture/best-pra...
Now if you have to consume an API you have no control of make sure you are mocking at the right layer, aka mocking the response, not the actual call to the API.
So first off, you could follow SOLID design principles and just use json objects in your Redux api methods and develop around mock data way before you ever send an api call.
A tool we use for generating mock data sets is Mockaroo.
Sometimes though, you just can’t replace having a real api with mock data. For that, we have our own sandbox environment that is a clone of our production stack. All the app data in our sandbox is generated by a library called Faker.
Everything is hard for me now. I'm getting old and can't learn as quickly. Part of it's the environment now too - mismanaged teams, 2x the tech/languages as past projects. I lost the drive to learn because the stuff I learnt in the past has all been throwaway work due to the constant switching. I just switched to a new team and can't even get the project running locally because the documentation sucks. What little they have are all videos. Give me a goddamn checklist, not some disorganized, incomplete, and outdated video.
I like to use Haskell and servant.
I encode the API as a servant type.
Implement a server with in-memory data structures.
I run the server and just change the endpoint the production client library hits. This is a language-agnostic mock.
But if there isn't a production client library yet, I get a Haskell client for free! And with a lot of work, could probably generate any language's HTTP client from the servant type for free.
mocks are useful when you're able to make them return different data for different operations to support a test case.
what does your api look like for configuring your in-memory server mock? I assume your test cases would interface with this?
The mock is just an in-memory implementation of the service API I'm mocking. It's a bit more complex, but you have APIs to create entities, fetch them by id, etc. And you actually generate ids, store them, query them.
So for, say, the Slack API. You'd create a workspace and some channels. Send some messages. And then when you ask for the chat history of a channel, it'll be the actual messages you send.
Slack is a bit more complicated because it would also include webhooks. Not impossible to wire up and send realistic ones. But it's of course more (fixed-cost) work. But if your business relies on this API so much, maybe it's worth it.
The fun part is if you do it this way, you can - in theory at least - run your test suite both against your mock and against the real thing.
The big killer feature here is servant and Haskell make it relatively easy to do this. The code is not complicated and it's hard to mess up. It can just be tedious. But it's good work for a junior engineer or new hire or intern to do.
What do you by a mock server API? Obviously reimplementing a server API that isn't yours is going to be pretty involved. If this is for testing you could stub out network calls - but I'm a bit unclear what are you trying to achieve or what the specific context is. If this is obvious to others then my apologies.
What's your tech stack?
If you use docker there are quite a few mocker-in-a-box solutions.
I use Java and Node, and created something basic [1] that does this for testing.
[1] https://github.com/acrontum/moxy
Found it really easy to mock server API with mswjs and its addon mswjs/data.
What are you having trouble with specifically? What services have you tried?