Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Architecture] Use a server client model #19

Open
sean-nicholas opened this issue Mar 15, 2019 · 2 comments
Open

[Architecture] Use a server client model #19

sean-nicholas opened this issue Mar 15, 2019 · 2 comments

Comments

@sean-nicholas
Copy link

First things first: Just brainstorming here ;)

I looked into exoframe as an alternative to now.sh. They use a server client architecture. The CLI is a client connecting to the server which does the deployment etc. I like this idea because you cloud write a webUI which uses the same REST API and could easy scale up / down your deployments, etc. from your mobile.

Do you think it is possible to have something like this in snow? Maybe you use the cli to create the initial cluster & deploy the snow server into it. Later the cli talks only to the server which does the heavy lifting.

I have no idea if this works with kubernetes, but wanted to share my thoughts :)

@petermikitsh
Copy link
Member

Client-server model

Before I began working on snow, I did my best to research alternatives. I, too, came across exoframe.

The benefits of a client-server model look appealing: instead of needing this basket of installed system dependencies, you instruct the server via REST endpoints to create deployments, update deployments, etc. If we were to explore such an approach, you'd still need kubectl on your system to initially authenticate to install the server component.

I considered this, but for an 0.x release, I wouldn't have the bandwidth to deliver it.

Dashboard

Kubernetes ships a feature called the Web UI (Dashboard): https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/

  • A UI dashboard for only viewing system state is one thing. Modifying the state of the system is another: we'd want to think about the security implications there. If your dashboard were to be compromised, your app could be taken down.
  • The Kubernetes dashboard is probably a little too powerful for people using snow. As you mention, we'd probably want our own (more limited) dashboard -- a GUI that had parity with the snow CLI commands. It would be fun to build such a thing. So many ideas, so little time! 😅
  • The dashboard could be built independently of the client/server model functionality (above).

Takeways

A better ecosystem surrounding snow would facilitate ease-of-use.

  • @snowjs/cli - Got this
  • @snowjs/dashboard - Web UI for cluster
  • @snowjs/server - REST interface for managing cluster

Taken to the next level:

  • @snowjs/app - Mobile client shipped to the app stores

@sean-nicholas
Copy link
Author

Great roadmap :) I totally understand that this is to much for a 0.x release.

I am happy to help in building such thinks. Unfortunately, I have no clue about kubernetes. If there is anything besides that, let me know how to help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants