Direction of wasp-lang
Had tinkered around with it for a week. Like the abstraction done by wasp but thus far I do see a bunch of hurdles for people that want to bring this to actual "saas" level like the direction Vercel is heading. Or maybe I'm wrong and that this is merely a starting point for saas creation and that people would have to break away from the abstraction once there is enough traction for them? Anyway curious on a bunch of stuff below
- having slightly more access to abstractions created
Abstraction is good but sometimes at a cost
E.g, like the oauth process flow is hidden from us, would be better if they are created and can be modified if needed in the template (possible to put up disclaimer or something on modifying it). Case in point, wanted to modify the loading screen that is waiting for the auth callback, or the callback path or password requirements etc
- Localization support or strategies
I think this would bring in even more awareness to the framework those helper components would need to be updated as well I guess
- Support for saml/sso or bring your own provider
I would imagine an saas that deals with b2b would need to have this to login from client's okta or something. This might be a deal breaker for consideration when really building a saas startup
- Feature flagging strategies
Coverage of recommended strategies for them (in doc or something ) for rolling out features or a/b testing (like an actual saas)
4 Replies
Hi @Fluffy. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Based on the knowledge sources provided, here's what I can share about the direction of Wasp:
- Access to Abstractions: Wasp aims to be a declarative language that understands a lot of web app concepts. It's designed to integrate seamlessly with popular technologies like React, CSS, JS, etc. However, it also has "hatches" or escape mechanisms that allow you to customize your web app in all the right places, but remain hidden until you need them. This suggests that while Wasp provides a high level of abstraction, it also allows for customization when needed. However, specific details about modifying the OAuth process flow or other elements are not provided in the sources. source (https://wasp-lang.dev/docs/vision)
- Localization Support: The sources do not provide any information about localization support or strategies in Wasp.
- Support for SAML/SSO: The sources do not provide any information about support for SAML/SSO or the ability to bring your own provider in Wasp.
- Feature Flagging Strategies: The sources do not provide any information about feature flagging strategies in Wasp.
For more detailed information or to suggest these features, you might want to reach out to the Wasp community or the developers directly. They have an active Discord channel (https://discord.com/channels/686873244791210014/1201827569641730078) and Github repository (https://github.com/wasp-lang/wasp/issues/584) where you can ask questions or make suggestions.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Fluffy, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
- more comprehensive docs
I do get that it's suppose to be beginner-friendly and allow people to quickly create their app, but I've encountered quite a few lack of documentation while working on it. Like using
signin function over signInForm if we want to really customize the appearance and the interactions of those workflows while using still using the auth. --skip-build if we want to deploy without rebuilding again (maybe making changes to server files ,etc that get overridden when building) to fly in this case.
Where I'm working at, we have a culture of documenting every "surface area" that we expose to prevent misuse and blaming when we do modify it down the road (even more so at enterprise level 😓 )
- Optimization strategies and best practices
Since it's been abstracted, are there strategies related to wasp implementation that optimize performance, caching, etc...
Lastly maybe making it more professional looking?
- People might wonder why server and client url are different when logging in/signing up from e.g google
- Hiding away "hello world" when visiting the server url in production, by returning a 301 redirect to the client url (or something similar would be good)
- Support different status code pages, 301, 302, 404 ( I saw that not found pages would work properly in the near future, but would be good if we can set the status code for those pages properly as well)
Sorry if I post in the wrong place (as it's a combination of questions(mainly), reviews, suggestions and rants 😅)
But liking what I see thus far (the studio visualization is a really nice touch!), hope to see more when it gets out from beta 🙏Oh hey this is awesome @Fluffy , thanks for taking the time to write such a review! Well you are right on spot regarding the stuff that is missing yet in Wasp!
The main reason while some "obvious" stuff is missing (more flexibility for Auth, improved docs, performance optimization, "hello world" on the server, ....) is because at the moment we are both pushing at the same time for feature completeness but also for innovative features, because we want to at the same time show the potential or where we want to go but also provide enough stability and features that it is not all vision but is also usable. The team is only 5 people at the moment so we are doing this trade-off, but we will likely be growing quite a bit very soon.
We have a couple of big breaking features/innovations we are working on right now (improving Prisma support, TS SDK/DSL, full stack modules) after which we are going to start pushing for 1.0 of Wasp, and for 1.0 we will be putting additional focus on feature completeness of the features we currently have + focus on security and performance, which is mostly stuff you mentioned above. We hope to get there by the end of this year!
As for specific things you listed:
Abstraction access / flexibility
So at Wasp we follow what we call the "onion" architecture, meaning that we provide multple level of abstracts for a feature, from high level to low-level, and you can "peel" these off as per your needs.
Auth is a great example: you can use Wasp's Auth UI, but you can drop lower if you need and instead us our Auth Operations (login action, signup action) and build your own Auth UI.
Some abstractions we had more time to "layer" up, some are yet in the pipeline, but the vision is to always have these multiple layers you can choose from and pick how much control you have. We are also always improving those based on user feedback, to make sure the API is right at each layer.
For example we have this in the PR right now: https://github.com/wasp-lang/wasp/pull/1993 -> Auth hooks, which allow you to plug in into the Auth flow while staying at the top level of the abstraction. We had quite some requests for these, and managed to both prioritize it as a feature recently and to have a good idea of what is needed when designing them.
Localization
Yes that is certainly in plan, we have a feature for that and we will likely be adding first-class support for it. That said, this will likely be something we wil be working on as part of 1.0 or a bit after it.
saml/sso or your own provider
This we are we are aware of -> we recently switched to Lucia and it's ecossytem for our Auth, including Arctic library, which gives us really good foundation to easly add support for different auth providers. Next effort will be to add support for much more of them + custom ones, which I hope we will be able to get on soon.
Feature flagging strategies
Oh yeah this would be great, also aware of it but left like it can wait post 1.0, as it is doable on your own if you wish at the moment mostly. But even having good recommendation in docs for start, and then also some first-class support, yeah that would make sense for sure.
More comprehensive docs
I agree -> we did a big rehaul of docs half a year ago, so they are in much better shape now, but there is always quite more work to do, and we also plan to put some autmation in place here to make it easier for us to keep everything up to date. We do hwoever have "api reference" blocks which should be playing the role of the whole surface area. What did you find missing regarding
signin vs signInForm? Missing examples on how to use signin, or something else? Also, what about --skip-build, what did you find missing there?
Optimization and best practices
Oh yes, this is happening for 1.0! Didn't want to dive into it too much while so many things are still shifting around in Beta.
More profesionally looking
Ha ok right, yeah we do have these small things that should be taken care of. We will be soon introducing solution for laoding via React Suspense + also the error boundary for error handling, so those should make that part quite nice. Hello world I still find quite useful when debugging to make sure server is all ok but yeah 100%, should display sometihng more professional.
So all together, thanks for awesome feedback, I will take a bit of time now to make sure I document some of it that we don't already have in our issues (and we have a lot of those on GitHub, we use them to track all the ideas and stuff we are working on, so you can also see quite a bit there regarding what we are improving or want to improve or add).
TLDR is really that yes, all those things need more work and we know! And is why we are still keeping Wasp in Beta. But we are really excited about the future and you can expect Wasp to be better and better on all of these points as time goes, + some super cool innovative stuff on top!
If you will have any more feedback in the future, pls do share and also ask away, it helps quite a bit, especially if you can in details explain what do you think is not good or how it could be better.
Oh and sorry you mentioned
People might wonder why server and client url are different when logging in/signing up from e.g google-> could you elaborate on this a bit? @miho do you know what this refers to?
I don't quite understand which URLs are different? 😄 We have the client URL and the server URL and they are different of course, since those are two separate deployments (client is a SPA, server is an API that the client contacts).
In the context of OAuth, the client redirect to the server and the process is done between the server (who has the OAuth secrets, the client shouldn't expose those) and Google. So, when the process ends and the user is created successfully, we go back to the client 🙂 that's the most secure way to do it when you have a SPA app on the client 🙂