[TBD] Gateway APIs

[wsdt]

Issue Type

[ ] bug report
[ x] feature request

Current Behavior

Right now every API is deployed as separate service, uses raw sql to save & query from the database which is very cumbersome to maintain & extend.

Expected Behavior

Consider adding at least an ORM such as TypeOrm which we have already for Teleportation to at least make the SQL part much easier to maintain, more reliable and faster to extend.

Would even consider slowly introducing a simple backend, that just handles all sorts of APIs for the frontend (e.g. NestJS, or if we want to go lower level NodeJS). This way caching, DB, API's etc. and even client-generation for the Gateway to not deal with Api routes could easily be streamlined resulting in way faster engineering.

or is there a particular reason why we have set up things the way they are?

[InoMurko]

Could we document the APIs we need to service the gateway? (and other services)
This goes well together with what @alvaro-ricotta was complaining about slow queries.

[wsdt]

Sure! The APIs I'm aware of (some of them might be stale though and should be cleaned if not used otherwise)

ops_boba/api/metatransaction-api

Deployed as serverless for every function & every network each. Functions are:

1. metaTransaction_getTestnetETH
2. metaTransaction_swapBOBAForETH
3. metaTransaction_swapNativeTokenForBOBA

---

ops_boba/api/watcher-api

Deployed as serverless for every function & network to serve the bridge history etc.
These services are then even dependent on ops_boba/api/monitor to fill the database with transactions so that the watcher-api can return them.

This could be either solved by using TheGraph (which would be the plan anyway now for Teleportation) or by having one backend instead of all these serverless functions that partially continiously run anyway.

• watcher_getL1Transactions.py
• watcher_getL2CrossDomainMessage.py
• watcher_getL2Deployments.py
• watcher_getL2PendingExits.py
• watcher_getL2Transactions.py
• watcher_getLayerZeroTransactions.py
• watcher_initiateL1Airdrop.py
• watcher_sendCrossDomainMessage.py

And most of these has a corresponding monitor within ops_boba/monitor/.

---

GraphQL

For governorProposalCreated and now with Teleportation we rely on TheGraph to index events (as discussed a few ago in our weekly).

Since we are extending our TheGraph support for (Boba) BNB etc. we could possibly rely more on that instead of all the watcher APIs.

---

CDN / Images

Some SVGs seem to be hosted on Boba Foundations github repository, such as:

• https://raw.githubusercontent.com/bobanetwork/token-list/main/assets/eth.svg
• https://raw.githubusercontent.com/bobanetwork/token-list/main/assets/uni.svg
• etc. within index.stories.tsx

We could consider a CDN or something similar in future.

---

Base Services (Gateway)

• Wallet Service: https://api-service.boba.network
• CoinGecko API: https://api.coingecko.com/api/v3/
• EthGasStation: https://ethgasstation.info/
• (in the same file there are also the meta tx APIs linked as listed above)

These APIs could potentially be included into a backend & cached to on one side reduce API requests & reduce the amount of API requests conducted by the enduser (e.g. aggregating into one request if possible, or batching them together etc) + client/server side caching in general.

---

Client-side rendering (React)

If speed is an issue in general, we could think about introducing SSR (Server side rendering) for our gateway, which would drastically improve SEO and performance. This wouldn't be an easy lift though.

---

Not necessarily used by the Gateway (or at least only mainnet), but could also be integrated into a potential backend:

• ops_boba/api/token-api

@InoMurko hope it helps!

[sk-enya]

This seems to be more over backend api related work so moved back to boba!