• have the query return a value, so that it can be performed on all members within the subscriber list.
• change name to something more specific "githubOrgMemberQuery"
• different query functions based on the targeted group.

a workflow to test the deployment of the app.

as of right now, add and echo aren't weaver components. they're simply functions being called into http requests. future more complicated calls will ofc be instilled and its essential for this layout to flow properly.

averaging around 857ms for logging in and 2FA. this is pretty good considering the server is able to encrypt, decrypt, and ship the data to the client in that timeframe. and yes, i know that one shouldn't focus too much on performance at the start of a project and I agree! nobody wants to miss a trend. however, since there isn't a clear vision of the end purpose in mind. i'll try to make this faster without lowering the encryption cost (13). i will upload statistics on performance eventually.

ability to initialize new subscribers in the novu database via service weaver based funcs. the current issue with this is due to the serialization requirements of service weaver.

#27 <- referred to here

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.

application works, but the code isn't written how i'd like it to be. it must be thought about differently, in a way that's both fresh and optimal.

as of rn, the js code is very MID. it's p much all cheats to give the illusion of functionality but it's really all just false orchestration. revamp JS code.

fetch is also just ugly. the display of the users feels very bland and non intuitive. it also only updates on reloading. the data should be transmitted live.

things to ponder on:

• how the fuck should a users groups be managed?
• a database within a database? that sounds ineffective.
• is localStorage a flexible roundabout for this? most likely not.
• websockets or sse? save this thought for later.
• why does the live data flicker?

so many things to think about here.

what to do next?

• revamp JS code (not necessary but will save frustration later on)
• research how accounts, and account data should be handled

as the title says