Hello there!
Hope you’re having a great week.
I’ve been spending time updating
my own complex Bubble app piece by piece to the new engine, and the initial results are very promising.
It does take a while to get the hang of, but once you get used to it you can build much more pixel-perfect designs in a logical way - and as a bonus they load and render much faster too!
This webinar by
Zubair is a great intro to the new engine, with some real working examples of how to build with the new engine.
Watch here on YouTube.
As the new responsive engine is based on Flexbox, it also makes sense to watch some tutorials on that,
here is a good one.
So far, I have only pushed my most simple pages to production using the new engine. More complex pages and single-page app designs might be worth holding out a little longer until the new engine exits beta.
I’m going to be covering the new responsive engine in detail in the coming issues, so do let me know if there are any particular topics or examples you’d like to see.
On to this week’s main topic…
Migrating data in your Bubble App
As I’ve said in previous issues, it makes send to spend a lot of time planning your data structure at the beginning of your project.
Fully understanding all your entities, and how they relate to one another is crucial to a successful build on Bubble - and can save hours of nightmares trying to fix things.
However, even if you spend all the time in the world planning your data structure - things change and sometimes you need to change the way your database is structured after your app has been released.
This has happened to me a few times recently. I’ve had to make some changes to where certain things are stored in my database.
And with over 100 active users and 30k+ responses collected in my database, I really try to avoid changing my data structure unless I can help it.
Thankfully, there are a few strategies you can use to migrate data from one type to another or to totally change your app’s data structure if you need to.
First thing’s first.
I really recommend having an admin page of your app where you can run these kind of jobs in production. The page should be secured so that not just any kind of user can access it.
In my app, every user has a yes/no field for ‘SysAdmin’.
So I set my own user’s ‘SysAdmin’ value to yes.
Then I can use it throughout my app to be able to access certain pages using a workflow rule. Example below.