Why genWeb3API.js

I’m wondering why have you decided to write a custom api client generator (genWeb3API.js) instead of using swagger’s or openapi’s own codegen?
If you for example write a code that uses the REST API directly, which is easy using the openapi codegen where you can get code for using the API in 100 languages, you cannot reuse this code in clients because the endpoints are completely different. At the same time, each time you create a Moralis SDK for another language you will need to port genWeb3API.js instead of just generating the code with openapi-codegen.
Wouldn’t it be better for at least having a similar endpoint structure, so that you only need to change the BASE_URL?
For example if I fetch the REST API directly a URL looks like this:

'https://deep-index.moralis.io/api/v2/address/nft?chain=eth&format=decimal'

so the generated code by the openapi-codegen will construct the address in that way when calling the generated function getNFTs() as per API definition.

But the endpoints of the own moralis server should look something like this
“myserver/functions/getNFTs/…”

so you cannot use the generated code by the openapi generator. Why don’t better use a URL format like this?:
“myserver/address/nft?chain=eth&format=decimal”
in that way you could easily reuse code and also save time if you port the SDK Moralis someday.

Alternatively, if you do think having 2 different enpoints is ok, then actually those two are separate REST APIs, wouldn’t then make sense to at least offer a swagger.json with the definition for the API using the own Moralis Server? So people could generate implementations for all languages and plattforms you don’t support yet.

There was a time when we used swagger.json, and then we decided to have only the javascript version of Moralis SDK.

I have a native app, I want to use the Moralis Web3 Rest API, I don’t want to use the JS SDK, is there a solution for that? since fetching the REST API directly on the client isn’t possible because of the topic about the API_KEY?

you can use cloud functions that use the REST API, or use the REST API on your backend if you have a separate backend

That’s not really a comfortable solution, please consider rethinking about my recommendation in the first posts and discuss with your team when you find the time, it would be way better for devs in my opinion.

Your recommendation is to use swagger to generate Moralis SDK api functionality for a different programming language?

Not really, my recommendation is to use the same API specification for both ends. If I write a code that fetches the REST API directly using the API KEY I would want to be able to use that same code to call all the API functions from the own Moralis Server with just replacing the BASE_URL (https://deep-index.moralis.io/api/v2) with MY_SERVER_URL (https://zdasdkjfcsr0us.grandmoralis.com:2053/server/api/v2"). This is currently not possible.

Maybe it would also be better to update the documentation, in my case I understood OK there is a REST API and the SDK provides functions to make usage of that API in a comfortable manner. Since my App is native instead of usgin the JS SDK I then went and generated native code to fetch the API, which is not hard, till I found out that I need an API_KEY for the calls and I cannot store that KEY on the clients. Then I found out that the SDK actually communicates with other endpoints, those of the own moralis server, so now I cannot use what I did. If both endpoints would have the same especification I could simply replace the BASE_URL and remove the API_KEY from the request and done.

Thanks for your suggestions, we will take this in consideration.

Hi, I put my implementation regarding this topic on hold and I’m doing something else in the meantime, but wanted to follow up and ask if you had time to discuss this internally and if I can have some expectations regarding changes based on our discussion?

I did discuss it, but there are no plans on short term in that direction. Eventually Moralis server will be open sourced if that helps you with anything.

Hmm, that’s dissapointing. I really don’t understand why you use 2 different REST API designs.
Is it time consuming generating a swagger.json? Because if not what would also help is that you offer a swagger.json for connecting to the own server like you already offer for the general REST API.