search

wasp-lang / wasp

The fastest way to develop full-stack web apps with React & Node.js.
https://wasp-lang.dev
MIT License
13.63k stars 1.18k forks source link

Support for multiple clients #1475

Open Martinsos opened 1 year ago

Martinsos commented 1 year ago

An ambitious idea: Wasp supporting multiple clients, and not only multiple web app clients, but potentially different types of clients: mobile app, chrome plugin, desktop app, ... .

So for example, we might want to have a project that has one server, but two web apps, one mobile app, and one chrome plugin.

What do clients share? They consume parts of the same server API, and possibly also share client logic (JS). Maybe something more, like knowledge about the auth and similar.

This sounds quite interesting to explore, and it opens up Wasp quite a bit.

One way this could go would be to define all of these clients in Wasp, directly. So we would have something like client declaration, and you could have multiple of those -> right now it is implicit that there is just one client. It is also currently implicit that this client is a web app. What if it was something else, like mobile app or chrome plugin? Would we have direct understanding and support for these (web-client declaration, mobile-client declaration, chrome-extension-client declaration)? Maybe for some, but I am guessing there are just too many types of clients to cover? What do we do about those then -> have some kind of custom-client declaration that covers all the rest, where you have to provide more plumbing yourself since we don't know much, but if you provide enough of it, it works?

This sounds pretty exciting! But it sounds also pretty undefined at the moment, it is hard to say how hard it is to pull this off and how useful it would end up being.

Another option might be to not have Wasp know about all the clients, but instead provide SDK or multiple SDKs, let's say for JS, that allow you to interact with basic functionality of your app via this SDK. For example, it could provide TS SDK for interacting with your queries and actions, and you can import that in any JS code and use it from there. So you can use that from mobile app (if written in TS), from chrome extension, ... -> but those you are managing on your own, outside of Wasp. We could even generate these SDKs for other languages, like Java, or Swift, to cover more potential clients. And they could cover usage of Operations, or API, or maybe something else.

Martinsos commented 1 year ago

@Neel-07 I deleted your comment because it is a summary generated by AI and doesn't bring anything to the conversation.

rosswaycaster commented 1 year ago

I was planning on experimenting with wrapping the generated client SPA with Capacitor to see if it would work as a mobile app!

Martinsos commented 1 year ago

@rosswaycaster that sounds quite interesting! Let me know if you manage to make some progress, I can possibly offer some advice on how best to do it, although right now it will almost certainly end up being hacky. But if we can learn something from it, it could inspire us for the future to upgrade Wasp to either support it directly or indirectly.

This conversation might be better fit for https://github.com/wasp-lang/wasp/issues/1088 btw.

Martinsos commented 7 months ago

The simplest form of Wasp generating something that then mobile and other clients can consume is "just" generating an (HTTP) API based on the Operations, as described here: https://github.com/wasp-lang/wasp/issues/863 .

Martinsos commented 7 months ago

We got a quite good question here: https://discord.com/channels/686873244791210014/1219117797364334612/1219117797364334612 -> What if I have a separate mobile app, and I am now building a Wasp app, and what that mobile app to also be able to use Wasp's auth?

This would be interesting to explore potentially! ALthough it is not super simple to answer, depends on what they really want.