note to self

[ethanwater]

The truth

The truth is that vivian is a pretty complicated project. The reason for this is due to many factors:

1. The ServiceWeaver framework; a really new framework being developed by Google that attempts to "morph" both the Monolithic and Micro-services infrastructure into one single binary. Since this approach is still new and not yet widely adapted, I can solely rely on documentation and experimentation to develop the application and various applets within it. I will describe why I chose this framework later.
2. Middleware; this issue somewhat correlates to the fact we are using the ServiceWeaver framework. Essentially, all the middleware has to be hand written by me since ServiceWeaver doesn't come with any middleware packages in its library. Keep in note, ServiceWeaver is purely a framework and nothing more.
3. The amount of applets; vivian consists of many different micro services and applets, to run in perfect orchestration. Or at least that's the goal- as of right now there are services, handlers, and ui for Echo, Login, and Fetch actions. The organization of these applets as of right now feels pretty cluttered- all being within the /server file (which should be changed to "app"). However this is the least problematic of the factors

The "AddUser" action is deprecated as of the most recent pull request: #19. Register will take its place for now.

Of course there are other factors but these are the main ones that lead to _vivian being a complex project. So it makes me think, "am I developing this the right way?". I believe not. When I began developing vivian, there was not set goal in mind as to its purpose, its infrastructure, nor its philosophy. All I knew was I wanted to make something cool, and now- after thousands of lines of code. I've realized I need to rethink the entire approach towards this project. Whether or not it becomes profitable or not, it's good to learn how to projects should be developed. I firmly believe that if the theoretical foundation or approach of a project is weak, it'll fail. So, how can I go about this?

the vision

all of the below fields are equally important and therefore deserve equal amounts of love and attention.

Purpose

Not yet established, still figuring this out.

Infrastructure

Now to the technical stuff, there are a couple of questions that must be decided:

• Are we using the best framework for the job?
• Is the slower development of ServiceWeaver worth the exchange for a slower response rate of Echo?
• Is Fiber up for use?
• Do we need WebSockets?
• Does performance really matter at this point?
• SQL, PostgresSQL, or noSQL?
• How can we assure solid security and authentication?
• and so on ...

Let's start by answering some of these based on the projects current status:

• The choice of which framework to use is purely based on our approach towards speed vs quality of development. It would take significant effort to transition frameworks at this point, but with the inclusion of premade middleware and other handy methods it may surely be worth the switch. However, ServiceWeaver makes the deployment of the software much easier and there is also the satisfaction of building a cloud-based web application with such new software.
• Do we need WebSockets? WebSockets are primarily used for applications such as chat apps like Discord, or other applications that require instant communication between the client and server. As of right now, I do not believe web sockets are necessary to implement at this moment.
• Does performance really matter? No, at least not anytime soon. The only scenario when performance should matter and be focused on is if vivian requires it (popularity => more usage => more request = need for better performance. The goal right now is to finish the app with its purpose purely in mind.
• SQL, PostgresSQL, or noSQL? Postgres. Since I dont intend vivian to have a wide range of fluctuating types and structures, Postgres allows for the most refined and consistent databases from what I've seen. If vivian were to allow things such as discussion boards and varying factors, then this can be reconsidered.
• How can we assure solid security and authentication? Do every test I can and prevent any possibility holes in the code. As of right now there is only sanitization protocols, and I am currently working on device recognition. TLS is a must and should be the primary focus before implementing any other features (besides from the tool itself).

Philosophy

I was reading some articles and stumbled upon this: https://theconversation.com/chinas-wechat-is-all-encompassing-but-low-key-a-chinese-media-scholar-explains-the-taoist-philosophy-behind-the-everything-apps-design-211785

I do not intend vivian to be an "everything app" but I do believe that no matter its purpose, the sense of "low-key" infiltration is a must. vivian must feel like an attachment to one's list of tools rather than a hinderance. It shouldn't feel "required" but it must seem necessary. It shouldn't feel like a drag, but more so a breeze that pushes you forward.

However philosophy doesn't just apply to the design of the app, but should also be applied to the development of it as well! It should be developed with care and purpose in mind. No matter the effect, the purpose and vision must be considered when developing. If not, it can leave to a dreadful experience and even more dreadful source code.

Approach

Everyone has different ways of approaching a project:

• Develop fast and dirty, then go back and fix it.
• Develop slow and precisely, no need to go back!

Of course the choice of approach depends on a variety of factors, most importantly being whether the field of the application is trending or not.

The approach heavily relies on the purpose and goal of the application and will be chosen accordingly once the use of vivian is final. As of right now, I believe it's best to go slow, since there is no rush nor purpose in mind as of yet.

So what now?

All I can do now, is continue developing and searching for new fresh ideas. I don't intend to remake the wheel, but rather improve upon it. This is a note to self, and will be edited as the app progresses.

note "vivian" is a placeholder name and will likely not be used for the final product.

[ethanwater]

vivian-lab is a playground for vivian2. the purpose of vivian-lab is to prototype infrastructure, deployment, and user interfaces. I imagine a lot of the source code will be used when developing the main application, just with tweaks to make it better.

[ethanwater]

For further emphasis on why ServiceWeaver is the framework of choice: It's faster and more cost efficient than most industry grade protocols, easy deployment management, efficient rolling update system, and it's focus on a distributed systems approach.

Plus, it's a completely fresh and new system challenging both Monolithic and Microservice systems by using what Google calls a Modular Monolith (sounds sexy).

It's simply the coolest and smartest choice here.

[ethanwater]

This repo has become the prototype, will be transferred to main.