Hey Daniel, just took a look, and that’s awesome stuff! I like how you’re caching the API responses to keep the site responsive after initial load, and of course it’s cool to see Coda being used as a backend for a user-facing site.
I worked on our API, so to give some feedback:
Your GitHub repo is set up well to omit the API token, but the actual token still made it into your compiled demo. I was able to get your API key by looking at the compiled source/network requests tab in the Chrome dev console, so your docs were an open library for some time. (To keep your account secure, we revoked that token on our end, so your site won’t load until it’s updated.)
The ideal thing to do is to have your own backend service that makes requests to the Coda API. That way your Coda token won’t get exposed to users, and you can also cache responses on your end. Note that our API does enforce some limits (currently 1000 requests/minute), so this wouldn’t scale for a super popular site for now until we look into raising the limit for use cases like this one
One thing we’d need to do on our end to let you use the token in React directly is support configuring “scopes” on a per-token basis. Currently Coda tokens grant access to your entire account, but you can imagine a world where a token grants read-only access to only certain tables in a certain doc, and not any of your other docs - perfect for something like this CMS
Anyway, nice work! Really stoked to see someone make this with our API.
Thank you so much for you feedback @oleg and for closing the gap from your side!
I was using react without ‘create-react-app’ before and already had a hard time to implement a .env. I was so happy when I realized this is part of create-react-app and I can hide the key, but it does not help if the request itself is visible
Yeah I guess scopes would make sense. Would it also work with some kind of ‘domain-restrictions’ where only allowed domains can use the token, or could people easily fake domains at the request?
So next step will totally be making a secure backend service with some caching there. 1000 requests/minute are still a lot for experiments right now (and with a wise caching system).
Hehe, no problem! There are a lot of parts here and it’s tough to make sure everything’s watertight, so to speak.
With regards to domain restrictions, there is something called CORS that would come in handy. We could in theory have our API server return a header that says that only codacms-js-demo.zettl.io is allowed to make requests using that token. But note that this is merely a header respected by popular browsers like Chrome – it wouldn’t stop someone from using that token outside of a browser, such as in their own Python or shell script or other environment that doesn’t respect web headers.
The 1000 requests/minute is something we set up on our end to help prevent someone accidentally overloading our servers with a ton of requests, i.e., writing a script that makes hundreds of requests a second. But again, if you (or anyone else) is thinking of taking the API further, we’re happy to evaluate requests to raise that limit for your account.
Hey @Johg_Ananda I didn’t continue with it that time.
As Coda & the Coda API evolved maybe it is time to have a second look.
What is your use case? Do you look for something like a library to implement in your web/app project or a no-code service to create websites with coda content or something else?
I have developed an app that I want to share with people but the lack of granular access control makes coda not ideal. I was thinking of retaining all the work in Coda by using it as the backend and then making a user model front end… does that make sense? @Daniel_Stieber
)
