This week we are getting ready to launch an early tester version of the Tableland Studio at https://studio.tableland.xyz. The Studio is the official tool to help you to easily build applications with Tableland. I won't go into detail on all the features of Studio here, we will have entire post on that. Of note however is that we have been using Vercel to deploy Studio during early development. This week as we stress tested Studio we found an interesting issue with deploying our api on Vercel.
Some background:
The Studio is built to help folks use Tableland for production level applications, but the Studio itself is also built using Tableland. This means the internal database that Studio uses to manage accounts, teams, projects, and so on, is… You guessed it, Tableland! These internal tables are owned and managed by the Tableland team. The Studio has an api that authenticates users and then handles requests to create and update account specific info. When one of these requests comes in, the api uses the Tableland SDK to write to our internal tables.
The problem:
While testing with one or two developers everything was working, but when we started hammering on the app with a large number of accounts and requests we started getting nonce_expired errors. We had configured the SDK with a nonce manager, and not really thought too much about the implications of how Vercel scales applications.
Under the hood Vercel uses serverless functions, the benefits of this are well known. However, the drawback to this is that the each instance of our api needs its own wallet configured with the correct Tableland ACL rules. In order to have a unique wallet per process the Studio api needs to have the wallet info in the env of the process. Looking backward, this almost seems obvious but we had been focussed on getting the product out the door and Vercel seemed to "just work".
The solution:
After some debugging and digging into Vercel docs, we didn't find an easy way to reconfigure how Vercel was deploying Studio. Our co-founder, Sander, had mentioned that he recently had a good experience trying out Railway. This seemed like a great opportunity to test Railway a bit more rigorously.
Sparing the details of our specific configuration, in less than 45 minutes we had fully switched to Railway. The setup and config made it simple to enable a per process env that solved the nonce_expired issue without any code changes.
“Every act of creation is first of all an act of destruction” \~P.P.
Switching to Railway worked like a charm and the team is generally exited about using Railway more, however being able to easily use serverless functions without these kind of nonce issues would be nice.
This problem has spurred some internal research into the state of the art for decentralized nonce management. No promises, but the Tableland team is hoping to, at least, come up with a longer post about this topic. Or potentially even release an open source tool to solve this using decentralized best practices.
Tableland Studio launch
This week we are getting ready to launch an early tester version of the Tableland Studio at https://studio.tableland.xyz. The Studio is the official tool to help you to easily build applications with Tableland. I won't go into detail on all the features of Studio here, we will have entire post on that. Of note however is that we have been using Vercel to deploy Studio during early development. This week as we stress tested Studio we found an interesting issue with deploying our api on Vercel.
Some background:
The Studio is built to help folks use Tableland for production level applications, but the Studio itself is also built using Tableland. This means the internal database that Studio uses to manage accounts, teams, projects, and so on, is… You guessed it, Tableland! These internal tables are owned and managed by the Tableland team. The Studio has an api that authenticates users and then handles requests to create and update account specific info. When one of these requests comes in, the api uses the Tableland SDK to write to our internal tables.
The problem:
While testing with one or two developers everything was working, but when we started hammering on the app with a large number of accounts and requests we started getting
nonce_expirederrors. We had configured the SDK with a nonce manager, and not really thought too much about the implications of how Vercel scales applications.Under the hood Vercel uses serverless functions, the benefits of this are well known. However, the drawback to this is that the each instance of our api needs its own wallet configured with the correct Tableland ACL rules. In order to have a unique wallet per process the Studio api needs to have the wallet info in the env of the process. Looking backward, this almost seems obvious but we had been focussed on getting the product out the door and Vercel seemed to "just work".
The solution:
After some debugging and digging into Vercel docs, we didn't find an easy way to reconfigure how Vercel was deploying Studio. Our co-founder, Sander, had mentioned that he recently had a good experience trying out Railway. This seemed like a great opportunity to test Railway a bit more rigorously. Sparing the details of our specific configuration, in less than 45 minutes we had fully switched to Railway. The setup and config made it simple to enable a per process env that solved the
nonce_expiredissue without any code changes.“Every act of creation is first of all an act of destruction” \~P.P.
Switching to Railway worked like a charm and the team is generally exited about using Railway more, however being able to easily use serverless functions without these kind of nonce issues would be nice.
This problem has spurred some internal research into the state of the art for decentralized nonce management. No promises, but the Tableland team is hoping to, at least, come up with a longer post about this topic. Or potentially even release an open source tool to solve this using decentralized best practices.
From SyncLinear.com | NOT-32