I recently tried to use the select action from supabase but it returned 0 rows,
after contacting the support this happens to be because I was still using the old supabase plugin instead of the new backend and was advised to switch.
The issue is that the new backend (which I am required to use as now I can’t even make a simple select query ( using only no-code)) work entirely differently that the old plugin was, all my collections are gone, everywhere I was using the user.isAuthenticated variable (which I use a lot of course ) point to an unknown variable, all my workflow actions from the plugin are broken.
As a user that used weweb only for the frontend, I am quite disappointed to see that I am this much impacted by an update that I am not going to use that much (while I completly understand that for a lot a users the new full stack approach is great).
I think it’s faire to ask that I would like the transition to be easier since now I’ve to make some serious work into making this change happens.
Maybe by creating a migration tool/ process to replace the previous plugin by the new backend everywhere it’s used automatically.
This is the objective of this post, to know if I am the only one thinking that, if you are a user in a similar situation as me please show interest in that post (like/comment) to let Weweb team know the importance of that matter.
Thank you
PS : after some recents testing the issue that I mentionned on the supabase select action is now fixed
Agreed. There needs to be a way to hide everything related to WeWeb backend if we have no intention of using it. The new UI is now bloated with things I have no use for and the front end features I was relying on have been obfuscated or removed entirely.
Wait how come you have to use the new backend? I don’t understand that.
But you’ve raised a valid point or concern for anyone moving from legacy backend to the new backend. @Joyce What happens if someone moves from legacy to the new backend, would they have to redo all their workflow actions? As I currently understand the system it seems like this would be the case.
Currently, if I try to use the workflow action « select » from Supabase, it’s not working (only using the anon token). The support told me that this wasn’t a bug and that to fix this I needed to migrate to the new backend.
You also need to remove that connection to the backend one as once you configure the interface plugin you’ll have duplicate actions for Supabase. To do this go to the Data & API tab and find the integrations section on the nav and disconnect supabase
Very odd that they told you this, it is still working on my side too.
I can only agree with you, it would be very appreciable from Weweb to understand that a lot of their users are here because they only want a frontend builder.
@Joyce is it planned for Weweb to remain also a frontend-only builder ? In that case, maybe you should reconsider the UX of frontend builders, because it’s true that you feel a bit put aside when you’re not using the data&api tab.
Just to clarify, yes it is planned for WeWeb to remain frontend-only friendly and yes, you can ABSOLUTELY use the Data & API tab with external backends. We didn’t do the migration for existing projects because the risk of breaking something in your apps would have been too big.
For new projects with an external backend, we recommend you use the Data & API tab.
For older projects with an external backend, if you want to use the Data & API tab, we recommend you duplicate the project and perform the migration at your own pace. And yes, you will need to recreate tables and workflows manually. We know it might be a hassle, especially for larger projects, but it’s the safest way to ensure nothing breaks in production.
hey @Joyce, could you maybe have a look at my post from yesterday evening? Its about using Supabase with we webs native Data&API and how to refresh the session… there’s also a little problem with then using the auth plugin, because then the invoke edge function from data & api doesn’t work anymore. ):
Thanks for the update. If the old plugin remains fully operational, then I have no concerns. The support team’s explanation left me a bit unsure, so thanks for the clarification !
I still have two concerns about this. After the news of WeWeb becoming full-stack low-code platform, I did explore the new features. We now have three options
But after exploration, I personally still believe the work required to set-up new project, integrating with backend, database and connecting it to the frontend side - the option 1 (the old way) is still most efficient for my projects and required cases, mainly due to the well-integrated plugin with supabase and supabase automate most of API endpoints. But the new options 2 and 3 took more steps and work to achieve the same result.
So my plan and desire is to still use the old plugin and collections in the future projects. But here the concern comes. You stated in your comment that “For new projects with an external backend, we recommend you use the Data & API tab.” I don’t have much incentive to switch to external backend with Data & API tab though it allow me to connect to supabase - because it took more work and using Data & API tab will make me count the backend subscription fees, too.
So what if I still stick to the old plugin for coming projects, instead of using supabase new plugin from external backend - Data & API, the weweb team will still support it for long term, right? Frontend Only with Old Plugin. I kind of need that assurance to make a long-term decision for the projects.
Some recommended suggestion like these fueled up my concern more as I sometime use REST Plugin, too.
The second concern is that before I start using weweb or start dedicating to this, I read and skim through the whole documentation list of weweb and supabase topics one by one - to explore what this combination is capable. I even memorize which topic is under which title. But today, when I checked the documentations, it is impossible to navigate Intro to collections | Documentation anymore, I couldn’t find it anywhere in the lists. It is searchable via search bar but it is not in the list. (I don’t know I am the only one). I knew it exists because I have read before. But new users exploring the documentation topic by topic won’t be much aware of the old plugin way.
I understand that weweb fullstack is still in the early stage of product life cycle and will improve later for better. It takes time. But the old plugin way with supabase is so powerful that it made me chose this tech stack. I still would like such documentation to be in the navigation as separate topics - because for new explorer like me who prefer the old way than weweb fullstack right now, will still choose weweb - even if it is front-end only with old plugin and collection as a data source - if one can discover what the old way is capable of and is easy.
Can you clarify what took longer with the new Supabase integration compared to using the plugin? We definitely don’t want the new experience to be worst so it’s something we’d want to look into and improve on.
Using the Data & API tab will not make you use a backend subscription if you are not using our backend features (i.e. WeWeb Tables, WeWeb Auth, and WeWeb Storage)
Yes, that’s intentional because we don’t want to confuse new users. Like I said above, the new integrations should not be a regression compared to the old plugins. On the contrary, most integrations already have more features than the old plugins and the goal is to improve them continuously. If you notice anything that’s more difficult or not possible with the new integration, please create a product ticket here to let us know so that the team can investigate.
Thanks for your reply. The last time I tried the backend features and watch YouTube about updates was around two to three days after the release. And after this comment, I did explore the documentations and watch new uploaded YouTube videos so that I am updated with new info.
First of all, I appreciate the update that the weweb backend acting as a middleman between browser and the database is great for security and that will definitely be essential for some large or enterprise projects. I am also relieved the adding table with Supabase Data Source as only frontend (I can see the option) won’t cost you any back-end fees. There are other advantageous like the views are more easily customizable and we can easily link the joint tables - much easier than before.
The reason why the integration took more work especially for front-end only users is as shown below: meaning the trade-off is good and worthy of extra work if you want better security, but the supabase integration with the view style did add more steps to filter collections or re-fetch collection again. I believe that’s make front-end users - who are so used to old way might think - Hmm, it is a bit hassle to go through all these steps - I am lazyyy :3 - while front-end projects won’t have any additional benefit of being more secure than before. Thus, less willing to move to new integration style, wanting to stick to old plugin or being resistant to change.
And, and, remember - we also have fetch collections in parallel action in plugin. That’s so useful. For views, I believe there isn’t still fetch views in parallel action. Without it, that will make us more work, too. TT (Forgive me for too demanding :D)
I don’t know whether this is technically possible to solve it or not. But I will make to sure to create a product ticket via the link you provided after this comment.
I also have an additional question:
Using the Data & API tab will not make you use a backend subscription if you are not using our backend features (i.e. WeWeb Tables, WeWeb Auth, and WeWeb Storage)
What if I use supabase integration as a data source and use tables and views in Data & API tab with views that pass through the project backend server (not front-end to direct database view) - but I won’t use any of weweb tables, weweb auth, or storage - will it be front-end only plan or will it become back-end plan, aslo? I am not certain about those.
Great feedback! Thanks so much for taking the time to put it together. Really appreciate it
If you use a WeWeb backend server, then yes, you’ll need to upgrade to launch+ when you exceed the limits of the free WeWeb cloud plan. I think a good way to frame things is: if at some point you spin up a WeWeb server (when you see the globe and are invited to choose the region of your server), then you are using WeWeb backend features and no-longer eligible to the “Front-end only” plan. Does that make sense?
