The goal was to prove that our Python code was horrible and needed to be switched to Golang implementation ASAP.

Rough start

I could not even start our Docker container because some Werkzeug, Flask and Locust combo made it all not work anymore. So I first had to untangle that mess. It turned out that some older code of Flask used a specific call to a function that does not exist anymore at the provided location.

For all who are interested, the actual error is: cannot import name 'BaseResponse' from 'werkzeug.wrappers'.

After that initial rough start I started out by mapping out how Docker actually works. What happens when you do docker pull or docker login for example. Turns out they are all just HTTP calls to a REST API backend. That returns some data and with that data we continue onward to more calls until all the data has been gotten for docker to actually create the containers and/or images.

Docker API

I wrote the simple Python PoC code for the DockerAPI client. In principle I can use that code now to get any image I want, but I do not use that. So I included that whole code into our Locust framework to make sure the test was always set up correctly, and that subsequent images were deleted.

I ran into the second problem. Images cannot be removed from a Docker registry by default. You have to enable that feature. So when I started talking to our devs, they said just forget about it. Do the setup code once, so that the image exists that is needed in a shared test repository and continue onward.

So I scrapped the entire code out of Locust and began again anew.

Concurrent issues

Next up came the problem that I wanted to only get credentials once, and share those credentials amongst the distributed workers. There were several hosts that each run multiple workers as separate processes. I wanted on each of those hosts, that one call got made by the worker process to get a nice token and share that token in memory with the rest. In comes SharedMemory by Python. I got it to finally work after fixing all my concurrent race condition failures, where there was no synchronised flag to make sure everybody waited on each other.

After all that code, the rest of the devs were that is cool but we do not need it. Just call the login at each start of the flow, it will create credentials and if there are already credentials it will return them. So again rip out the code written so far and start anew.

Finally on my way

Started again with the new flow and now I got a nice test up and running. The data returned was a bit baffling and showed our Python code was not the bottleneck as previously thought, hoped for. It was our Nginx reverse proxy setup. Split out the nginx pods unto their own and updated the config to handle things a bit better and give more threads and workers basically.

Okay after fixing the nginx pods, then ran the tests again and it turned out the Docker registry itself was a bottleneck. It just could not cope in terms of memory usage and freeing up stuff. We use Redis as our cache layer and Google Cloud Storage (GCS) as our bucket to actually store the data retrieved by Docker registry.

Breathing room

We had so much services jammed together in one pod it was crazy. Basically one pod ran the following services: – Nginx – Redis – Docker registry – Flask app

Then there was no control of what pod ran what services, so it could be that one pod ran 2 nginx + redis + docker registry + flask, whilst another ran only docker registry + flask. So back to basics, get one service per pod and split off the docker registry unto it's own node. Now we have the following setup:

• Nodepool A:
  • Three nodes
    • running one pod each of Nginx
    • running one pod each of Flask
    • running one pod total of Redis
• Nodepool B:
  • Three nodes
    • running one pod each of Docker Registry

Now that that was cleared up, the next bottleneck seemed to be Redis? So I turned to Redis and it's config and found out we actually were not using the staging Redis but the production Redis ?!?!?!

I quickly changed that config and made it so there was one node running a dedicated Redis. So the full situation becomes:

• Nodepool A:
  • Three nodes
    • running one pod each of Nginx
    • running one pod each of Flask
• Nodepool B:
  • Three nodes
    • running one pod each of Docker Registry
• Nodepool C:
  • One node
    • running one pod total of Redis

Okay, now can we finally move onward to find out that the Python code itself is so slow?

gunicorn

Well not so fast. Turns out that gunicorn was behaving badly and might do with some optimisation. gunicorn uses different worker classes and if we do not feed it the right ones with the right parameters it might actually be blocking. The reason I started looking down this rabbit hole was because of the gunicorn logs stating they ran out of workers.

After much experimenting on what parameters work best, turns out the best one that worked for us was the following:

CONCURRENCY_SETTING=$(python3 -c 'import multiprocessing as mp; print(mp.cpu_count() * 2)')
exec /usr/local/bin/gunicorn -n internal_auth_secret -w${CONCURRENCY_SETTING} -k gevent --worker-connections=1000 -b 0.0.0.0:8000 internal_auth_secret:app -t 180

Meaning use the gevent type worker class, with 1000 worker connections. Also use a total amount of workers to twice the amount of cores available to us in whatever host we are running as. This also meant it is dynamic to the point where if we would ever upgrade the hardware of the node underlying the pod it will grow with it automatically without us having to make sure we also update the amount of workers.

Conclusion

After fixing all the infrastructure setup of correctly allocating memory and CPU to each of the services, coupled with separating them out to make sure each of them gets the appropriate amount needed. Making sure our nginx was configured correctly. Followed by actually configuring the services in staging correctly to point at services in staging rather than production, followed by configuring the gunicorn service and fine-tuning it, there was still a slight bottleneck.

Yeey, finally Python code is slow and dumb and move on to Golang. Hold on, let us first see what is being the bottleneck. I made some call graphs using the following module https://github.com/daneads/pycallgraph2. It showed that the bottleneck was partly in our shared library code that handled authentication and also the way we were determining when to call that particular function. Finally the culprit has been located.

To fix the shared library code was easy, just improved the for loops and small optimizations in terms of what to store so we do not do a constant looking up of the same values. Cache more in Redis, then also use a Redis connection pool rather than starting up a new connection every time for each query.

To fix the problem of knowing when to call the function in the shared code was a literal one if else statement added to the previously declaring of the variable logic. It was a code fix of 44 characters that resulted in an improvement of the total time spent. The longest before this fix was 465ms on the shared library code path. After fixing both it was only around 60ms. So instead of the code being able to handle roughly 2 per second we could now handle roughly 15 per second per worker per worker_connection.

After that roller-coaster of a ride, I made sure we could handle millions of requests coming in rather than just couple of hundred. The next optimisations lie in Network I/O and other factors. Even if we would move towards Golang implementation it might gain us 1ms max in terms of code maybe, that is even highly optimistic and probably not even realistic. The rest lies in the fact that we have a nginx going to a docker registry talking to another service running somewhere else again on the network that talks to Redis. Those round trip times are starting to add up.

However that is for another time. Right now we got enough to make sure we can get through the next years of running our service. If we need more, just scale the entire setup to include more nodes, until the bottleneck is network throughput/bandwith. Then we will revisit this.

#100DaysToOffload #DevOps #python

Getting an ember

Everyone that teaches to make/create your own fire will tell you that one of the most difficult things is getting an ember. A small hot enough material that will ignite the rest of the fuel. Well for me that was getting the source code for Docker registry (aka distribution) and getting it to compile and making sure I had the dependencies. They use an old school way using this tool called vndr which I am not familiar with since I am not an old school Golang developer.

After making sure the vendor.conf and vndr could play nicely and getting sucked down the rabbit hole of GO111MODULE to be switched off and what that does, in order to get my development environment to be able to follow the imports. So finally I have a somewhat working thing, but I cannot make changes yet. This actually brought back a memory of long ago trying to do some early Golang development. That is I like to separate out my dependencies and code. I think having a workspace of sorts that is your Git checkout and a whole separate other static dependency location is nice. For example, let us say you are working on two projects in Python.

One is your library you want to use and the other is a project utilizing that library. Then if you want to make a change to your library, you do not want to do it directly in the project utilizing the library. You would want to have changes being arbitrarily worked on for the library separate from the project utilizing it. On your machine you might have two Git folders, one the library and the other the project. Then the project might have a dependency file that imports the library. You could even specify the Git branch in there. So you make the changes to your library, commit and push to a new branch. Checkout a new branch in the project and update the dependency file to the new branch and see if it all works.

Then just having virtual environments makes the most sense to me as you do not want everyone to use the same version of something or have to be force to use the same version. I digress.

So since I have one folder that has my Git code, and another that is the dependency I thought I would do the naive thing and just clone the repo into where the dependency is currently held and work on the code with symlinks. Nope. That did not work. Then I tried to work directly in the dependency and that did not work.

At some point I just gave up on this and started to work without autocomplete, syntax highlighting and any IDE features whatsoever and just a glorified text editor is all I had.

Fanning the ember

However small the ember, I needed to fan it in order to get the flame. Now I wanted to introduce the Firebase to our codebase that is sharing code with the Docker registry codebase. In essence we use it as a library as well. So in my project I just added the Firebase, no problem there. That took like 5 minutes. Then however came the problem that the Docker codebase had an old dependency on the GCP stuff. That messed things up. It caused a conflict I could not fix in our project codebase alone. So I had to update the GCP stuff for Docker registry (distribution codebase).

That meant just updating the reference right? Nope. I had to refactor the GCS storage layer as well with the newer calls and make them as close as I could to being backwards compatible/feature parity. Thinking I have done so, I try to recompile my code but it still does not use the new dependency I laid out. I just did a stupid thing and forked the code into my own Github, then changed all references to point to my Github instead of Docker. I since learned you can remap this in go.mod and probably also in vendor.conf but yeah. My hair already looked liked the Prodigy at this point so I might as well stay committed.

So I got a nice code base to work off of, and add my Firestore to our project using that augmented Docker codebase. Done, there is a flame going, starting to get bigger.

Fire, fire

Then I check the differences between this Firestore cache layer and our Redis one. It is tremendous, huge and insanely obvious what we should do after I answered the question if it is actually faster. Every call to the Firestore API to get a response takes a minimal of 1 second since that is the rate limit. So yeah, get the bucket of water and a bucket of sand to cover up this fire to put it out immediately.

Now I will say, we could improve our algorithm in the codebase and bypass how Docker gets tags by making one giant query and sending it to Firestore making it that we only pay a cost of 1 second once to get everything and it would be blazing fast afterwards since we would have everything and it would need to be kept in memory though. So it is still faster to query and store things in Redis.

#100DaysToOffload #docker #golang

Stat has that information

So my first inclination was that the os.Stat call has that information. It sort of does, in a way, but only for Linux. There is a Sys() method on the fs.FileInfo which returns a specific struct on Linux.

package main

import (
	"fmt"
	"os"
	"syscall"
)

func main() {
	info, err := os.Stat("/tmp/some.file")
	if err != nil {
		fmt.Printf("%s", err)
	}
	if data, ok := info.Sys().(*syscall.Stat_t); ok {
		fmt.Printf("UID: %d\n", data.Uid)
	}
}

Is an example of how you get to that part and if you call syscall.Getuid() you can check it if they are the same and therefore if you at least own the resource. However that does not mean it is writable yet.

Permission bit logic

I tried to finagle some bitwise logic with the permission bits, but again they only work on Linux and truth be told I never trusted myself that I got it to work.

Sidetrack to Java

So in Java there has been this thing since forever. You give it a path, and it tells you if it is writable. It is a static method and easy to use. Why does this not exist in Golang?!?!?

Solution

So I did finally create a solution that was tailored for Unix and Windows separately.

Windows

The Windows solution made me go down a rabbit hole, read up on Win32 API structs and methods on the Microsoft docs and dig deep down in the source of Go itself to figure out what I have access to. I will just show you the code:

package main

import (
	"fmt"
	"syscall"
)

// https://learn.microsoft.com/en-us/windows/win32/fileio/file-access-rights-constants
const FILE_APPEND_FILE = 0x00000002

// https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew#parameters at dwShareMode
const FILE_LOCK = 0x00000000

func main() {
	// Checks if directory is writable
	if hwnd, err := syscall.CreateFile(syscall.StringToUTF16Ptr("C:\\Windows\\system32"), FILE_APPEND_FILE, FILE_LOCK, nil, syscall.OPEN_EXISTING, syscall.FILE_FLAG_BACKUP_SEMANTICS|syscall.FILE_FLAG_OPEN_REPARSE_POINT, 0); err == nil {
		if err = syscall.CloseHandle(hwnd); err != nil {
			fmt.Printf("%s\n", err)
		}
		fmt.Printf("This directory is writable")
	}
}

So yeah, a syscall to CreateFile to open a handle to a directory. I cannot figure out why you need to create a file to get a handle to be able to tell if you can write to a directory, even more so because CreateDirectoryW is also an actual call in the Win32 API, which is the only one that can actually create a directory. This is so confusing.

Linux / MacOSX

The other solution was sort of similar but much easier. There is a nice syscall to Access.

package main

import (
	"fmt"
	"syscall"
)

func main() {
	// Checks if directory is writable
	if err := syscall.Access("/opt/", syscall.O_RDWR); err == nil {
		fmt.Printf("This directory is writable")
	}
}

Conclusion

I feel like all of this code can be hidden away in the Golang standard library and give us a nice os.IsWritable(path string) bool function signature for it.

#100DaysToOffload #devlife #golang

JVC SEA-33

It is a JVC SEA-33 Graphic Equalizer. This thing was made in the time that everything was analogue, and when mixing was not always done correctly. So what you could do is hook this thing up in your sound flow and change the amplifying or suppressing of certain frequencies to help bring out a better sound experience. Now my laptop has a 3.5mm Jack to two RCA adapter cable, and my headphones has a 6.3mm to two RCA adapter cable to hook everything up. Of course my laptop has a digital soundcard so it is not as effective as it could be, yet still I can tweak things and I just like the fact I have it working. Furthermore I can hook it up again to my record player into my amplifier in the future and then it will all work as it should be.

Kintsugi

This brings me way totally into another area, but we ordered a cake platter and it got delivered shattered. Yeah I know, there is no segue into this. Instead of returning it, we heard of kintsugi which is basically using a golden glue substance to mend broken vases, porcelain- and glassware. I liked this idea and now have a cool set piece which looks much better than the new version we got after reporting this broken delivery to customer service.

Limiting waste

I like the idea of minimizing waste and not just throw out stuff that could be repaired for a smaller fee than buying it new. What I do miss sometimes though is the fact that it is not appreciated by the companies who make their products that you start repairing them instead of buying new stuff. They will make it so difficult and hard to get into stuff or have the parts you can use to repair in a catalog somewhere.

Like the old days when the first PCs came to the market for consumers, everyone got a giant list of part numbers and you could just order more specific parts if you needed them again. Now we actually have to fight for our right to repair stuff we already bought. It should be ours to do with what we want, but that control has long slipped from us consumers.

Knowledge

I also have the idea a certain body of knowledge has been forgotten, or is in the process of being forgotten and that is worrying. Not only because it might set us back in development as a species but also because it might mean we are stuck in a loop or will repeat past mistakes.

Advice

My advice is to just buy old stuff and repurpose it if you feel like it. I still want to buy an old radio from the 60s and put in a Raspberry Pi Zero or equivalent and make it a bluetooth enabled speaker system that can also play YouTube and other songs, yet it still being a wonderful piece to look at. It will be a nice hybrid between analogue and digital, the past being brought into the future.

I have an old PC, 486DX2/50MHz, lying here that will have a running server on the network serving a real site. Obviously behind a TLS offloading proxy but it will still be serving the webpage. I hooked it up to my giant 65” Sony TV and I just loved the fact I held 30 year old tech that still worked and could fulfill a job today.

I also operated a saw that belonged to my great grand father, who I've met, and I learned that it might have been my great great grand father's even. That tool easily has been in my family's hands for more than a 100 years, and I intend to further that lifespan. It is wonderful that still exists. It works beautiful and you cannot buy a similar product anymore these days.

There something beautiful in that old things keep finding purposes and trying to get old things to fulfill a new purpose is fun to do. I do not think my dad in his 20s ever thought my son in his 30s will use this. Who knows what kind of tech I will buy that my children will repurpose in the future.

#100DaysToOffload #devlife

Uniqueness

I love the uniqueness of those eras pertaining to the products. Also the freedom and knowledge of understanding the product, making it easy to tinker with it and naturally making it a status symbol. If you know and understand more you are smarter, better, stronger and overall a much more interesting of a human being than those others that do not even know what a motherboard is. I thoroughly enjoyed the weekends pouring over catalogues with my father and just hand picking the best items for our custom built PC. Waiting for the parts to arrive, installing them, and finally after weeks and months of this process flicking the switch and hoping you did not screw up. It lights up, it shows a boot prompt and the BIOS screen. There was a moment of pure joy there.

Networking

The day we spend an entire afternoon installing Novell Netware and running a special cross data cable, which was a bright pinkish/orange, from one PC in my bedroom to the computer on the same floor in my father's office to finally copy a file over and seeing it being transferred was amazing. What was even more amazing was that my mother and sister had no clue what we were doing, let alone sharing in our joy.

There was also another way of networking and that was not just through the newly arriving Internet but just locally with people. Knowing where to go to get the good games and items. Secrets on floppy disks that you could loan from the public library and also people that put viruses on them.

First virus

My first virus I do not know exactly how I got it, but I suspect the floppy disk that held Doom I got from the public library. I had a 486DX2/66MHz, 4Mb RAM, 20Mb hard disk and, the best feature, a SoundBlaster Pro sound card. I cannot remember the graphics, but I believe it was a standard VGA setup. Video cards were not a thing back then, as it was unaffordable and only ever used for businesses that worked in an industry that needed such a thing.

I could not play a lot of games, but I could always shuffle around some games. That is what I did most of the time. I would have a lot of files on there. Most of them pictures I created, or some game or another. Of course Windows 3.11 took a lot of space too. A whopping 8Mb. So as I was in the process of swapping out I think Jill of the Jungle for Doom, suddenly my PC would not boot anymore normally.

I rebooted, and it loaded up my prompt and all the letters starting falling down. I could not input any commands anymore. What ended up happening was that I had to loan another HDD to install MS-DOS there and “fix” my HDD by copying over all the unspoiled MS-DOS files.

I installed a anti virus program for the first time ever and I ran it. It found some more things on my hard drive and I was wondering how long I had been infected for and where it came from.

Bringing the past with me

I wondered if it was possible to revisit that time in the present. I bought a 486DX2/50MHz this time and it got a bit better specs except of course a SoundBlaster sound card. It does have networking now though and I tested it with my local LAN network. I could copy a file over FTP from my Dell XPS super charged laptop from 2021 to a PC running MS-DOS 6.22 from 1993. I will tell you, the moment I got it all working I was jumping up and down again with joy. It instantly took me back to those olden days.

Now my project for this particular machine is to get a small screen to hook up to the VGA port and use the Molex cable to DC to power said monitor. Then it is a self contained system. Like a giant Raspberry Pi. After that I want to get a HTTP server on there to serve some files and make it the actual server for a website for a company called Studio Vlegel. Then make a game and have my friends at Studio Vlegel make a piece on the casing of the PC. After that sell this artwork as a statement piece.

Artwork

Something about getting the maximum with minimal resources, forgotten tech and also not discarding old tech. At the same time it is a bit of a jab at modern hardware with all their specs (especially servers) and the thing they do can be solved with a desktop computer from the 90s.

It is also an homage to the demo scene of yore. It still exists to some degree luckily and I want to sell the PC with the only copy of the game and source code of the website with server on there. Maybe we will sell floppy disks with the game on there as well in a limited fashion.

Coding for DOS

This gets me to coding for DOS. I never did that way back when. Now though I have a nice setup using Open Watcom C/C++ Version 2.0, picotcp4dos and just an editor. You can use VSCode, vim or emacs or anything else. I can now easily compile for DOS and successfully done so already. To be fair I think most would program direct in Assembly back then and I could still do that, but I am not that far advanced....yet.

The first time I compiled and shipped the binary to my actual hardware machine and seeing it work was amazing.

So stay tuned and in the future there will be a server added to the statistics that has an OS tag MS-DOS 6.22.

#100DaysToOffload #msdos #art

Then there are other options like running a FTP server yourself to share them, but that is not very intuitive to non-tech people. So you have to use a service of some kind, we settled on Dropbox in this case. Now getting away from just helping out a friend.

How about helping someone in my own household. I have some videos/pictures I want to send to another machine very easily and directly. I could use Bluetooth but it is horrible at file transfer specifically. The rest it does quite nicely. So if I transfer from my PC or device to another I usually just start a python3 -m http.server in the directory holding the files and then downloading the files I need.

Every time I run into this problem I find myself asking why are these seemingly so simple and core functionalities so difficult to implement. Even if everyone would run Windows, it is not guaranteed to work because I have a Windows machine in my network and I cannot get it to share files with any other machine.

Casual on the go sharing

Let us say you want to quickly share a file with a friend you happened to run into. You cannot share it via Bluetooth you will be standing there for 10 minutes. You either have to e-mail it, but then what mail address? You have to send it through some sort of messaging service, but then do you have them in that particular service?

Why can I not just drag and drop a file to this person's contact information and they will get the file? This should seem very easy to attain for a mobile phone OS.

If there is another way like NFC to share the file instantly that would be wonderful, but I have not found it yet. This is not limited to files though, what about Spotify songs, YouTube videos, webcomics, or anything else digital you can think of.

#100DaysToOffload #devlife

I just have one thought/question; why?

Why indeed

Well it seems like more and more was pulled into the frontend as time passed on, mainly to free up the backend to do the real processing. Like number crunching, data processing and so on. Which makes sense, but now it is weird to say the state of an application should be as close to the user as possible. Also servers are now more than capable of doing both work, and therefore the natural conclusion is that since most of the things were in the frontend anyway now; why not move the whole thing to the frontend?

The thing is that it makes the codebase more difficult to manage, you introduce unwanted complexity let alone making it secure. The whole codebase has so many extra dependencies and vulnerabilities since a lot of Server Side Template Injection (SSTI) plague the landscape now and have been fixed/found already in the old backend languages.

Of course it seems convenient, but let's take the data models that you want to use. You define them either from the frontend perspective or backend perspective first. In the frontend you might only want first name and an e-mail address, for example. Then in the backend you want to have maybe something more than just first name and an email address. How about a password to login? Or a session id, or maybe just an id in general for the databases so you can store multiple combinations of people? Then you have to transform schemas or build them differently. So you get views or something equivalent and suddenly everything is back to this again.

I would steer away from having the whole application in one language with one library/framework since nothing so far checks all the boxes and covers all the bases.

#100DaysToOffload #frontend #JavaScript #devlife

Rust

Rustlang seems to be the culprit since ever since that relative new language came to the scene of programming languages. Nowadays everything is in Rust. Every new project at least and they are using for example yew or maybe leptos. It aims at even rendering HTML tags as some sort of bizarre JSX deal.

So we went from having everything in C for the browser. Code that could be made to fit unto a blackboard but was difficult to be approached by everyone. Slowly but surely more languages came and some were tere to try to make C easier. Like PHP, which is essentially C for the web. Now more and more processing power came to the frontend and the backend has to do more and more since it has a lot of more responsibilities. So as time went on, showing the UI went to the frontend. Then maybe interactivity went to the frontend, then also login, state and pretty much everything you can think of.

Now we are slowly but surely swinging back the other way. Having everything in C, I mean Rust. We are back right where we were 40 years ago.

What a day to be alive.

Carbon

There exists a new language in town and it is called Carbon which I think is to be a stab at Rust, and at the very least a small attack. It aims to be a better C++ that supports the full stack experience. So naturally Google has to get it's paws in this pie.

It seems very odd to me that people condemn PHP for the silly wrong language it is, but seem to take to this Rust being a full stack environment like it is the next best thing and the way forward into the future. As if it is the best idea ever and why did nobody think of it before today? It is just old wine in new bottles.

#100DaysToOffload #carbon #rust #backend

Remember REST?

Remember when REST first was a big thing. The idea that you would have stateless calls to the backend that just ships data? That was revolutionary. Then all sites became REST API sites. The SPA got borne out of it. Then everything became an SPA. Whether that fit or not. Handling any type of state/session data became extremely difficult and also the calls to get data from the database through some reverse proxies to ultimately end up in the frontend after several transpiling steps made everything worse in most every way.

There are many other ways to program the application. You had the MVC pattern, MVVM or any of the MV* patterns. These still hold value to this day. I think it is being skipped because it is so old and not new. Not exciting, yeah yeah tech is boring is good post coming. Well not really. Try to make tech exciting and challenging, but not just for the sake of making it difficult for you or following a trend that seems to be forming.

Then there is the fact you do the entire thing in either the backend or frontend that seems to be prevailing now. Which brings with it this idea of following the caravan out into the desert where everyone thinks someone else will know the way to the oasis and they all end up dying in the desert because of it.

I have been in so many projects and every time they reached for a web application with a login screen and everything being behind REST API. The next thing that always has to happen is how to secure the REST API? Then we are always building everything twice, the data models get created in the backend and then have to be exposed to the frontend and because that is in TypeScript we have the data model definitions (schemas) now twice. Once in the backend for let's say Java and Hibernate and in the frontend for Angular. After pointing this out, we still keep on the same train tracks. Why? Well we can charge the customer twice for the same work.

Pick the right tool

Just keep your options open and choose the right tool for the job. Not just take GraphQL which is nothing more than a database explorer disguised as a RPC framework. When I am working on my personal sites, I try to make it as simple as possible and not do double work. So a MVC app works perfect for me.

#100DaysToOffload #devlife

Why does it even exist

I am having a hard time figuring out why this even exists as being a thing. It sounds like someone is thinking highly of themselves and go this thing I thought of that nobody has done before needs to be shared with the world and it will make me famous. Then it is something that not only already existed but is used globally and it is the exact same idea that already exists but now somehow transformed into their own idea.

It claims to transform a regular html site into a realtime application by loading in some JavaScript.

That is exactly what JavaScript already does. Not only that, it is apparently realtime, which I think is definitely misused here.

I just do not like these frameworks that try to claim they are superior and did something amazing, where in reality they did nothing really.

Something impressive

If you want to make something truly impressive, use the basic tools that are there and build upon it. Like using construction materials and tools to create a doll house for example. Not try and sell to people see this wood and tools, it can turn any room into one filled with a dollhouse, you just have to create it.

#100DaysToOffload #devlife