This is why I'm eagerly waiting for LiveView Native. That will remove the need for front-end APIs entirely.
775 karma · joined November 1, 2011
Also the fact that you have to setup API endpoints for your data, with liveview, you have direct access to the data. You can load any state with a function call instead of having to develop a separate endpoint for your frontend, handle hydration etc... You need real-time updates? It's done out of the box, you don't have to think about it. With react, that stuff is just ALOT to do.
I ended up removing a lot of controllers from my codebase that was there just to service the react front-end. Having those controllers do not service as the "API" of the app. Specs for front-end apis and core APIs are usually quite different based on my experience.
The easiest way I can explain it is LiveView is the least friction between thought and output. React / TypeScript just gets in the way because of all the choice and abstractions you have to build for it.
Don't get me wrong, React still has it's place, there are things I would still use react for, like if I need to render something visually rich, like a flow diagram (reactflow.dev), or video component, or make something like Figma, or a calendar / gantt chart, but for most front-end UIs (95%) you just don't need React.
The main reason for that is, the LiveView test framework is super simple to work with. I didn't write any tests when I was doing React / TypeScript just because it seemed so cumbersome to setup. Having a test suite that works out of the box made me write more tests for my front-end.
Not having to build API endpoints for my react components is also a huge accelerator in productivity.
In the end I ended up writing less code, with more polished / well tested front-end.
You can watch the video of what I built with LiveView here https://instellar.app
Thank you for your feedback.
For error handling when the task fails it sends a message to the genserver we can also use that opportunity to handle retry, or do a strategy change where after first failure we throw it into a job queue.
This way we optimize for user experience and at the same time have a robust strategy for handling failure. I guess that can be another blog post on its own.
Once it's delivered the entire runtime / lifecycle / upgrading / bootstrapping is managed by LXD/LXC containers.
It's definitely possible to open up PAKman's support for other build environments. I mean at the end of the day it's just an alpine linux package. As long as you can use alpine's package manager it should work.
https://instellar.app can also serve as a repository for your package. This was an option we considered to enable earlier, but figured people might just want a fully integrated solution.
In this post I show you how our product instellar.app handles multi cloud deployments. Instellar also makes it easy for you to manage multiple installations of your apps.
Installations basically turn your single tenant app into a multi-tenant app without having to manually code your app to support multi-tenancy.
We also give you a sneak preview of some of the work going into making Rails and Python based Apps compatible with Instellar.app!
Hope you like it!
If there anything else that I've not covered please let me know. Would greatly appreciate the feedback.
It does load balancing / automatic ssl issuing out of the box. It will also allow you to scale horizontally. I’m working towards making it public soon.
Currently my solution works for Elixir / Phoenix and static pages. But I'm working on expanding to ruby / rails and nodeJS based frameworks.
I see this in all of the things they do.
The one thing you see from Apple is though. Once they choose to do something they don't give up easily. Case in point Apple Maps. When they launched it they met with a lot of criticism. Now they're going back to the drawing board and re-doing the entire thing.
They really don't give up. I admire that about them.
p.s. If someone hasn't watched Foundation on Apple TV+, I highly recommend it.
Building a successful business is difficult. A great idea / execution / being resilient will always get you a good share of the pie. That's the beauty of free market. Just because 1 or 2 people don't like you doesn't mean the whole world doesn't like you.
I think the author is making Stripe / YC much larger / bigger than it is.
If the author is reading this. Just focus on building and shipping the best product. Everything else will work itself out.
Our Management team are mostly non-software people, generally they were the problem. Not having the right education / understanding.
Everyone wants to get into tech. Not many people are well-equipped to do so.
They had hired people who knew nothing about building software (before me joining), most likely those people have never really built and shipped anything. Everyone on the management was under the impression that software is easy and everything needs to be delivered on time and if it's delayed we need to throw more money at the problem and that would solve the problem. They would continuously ask for "timelines" and never understood the word "estimate". They knew the definition of the word but could never accept the reality of the definition.
I was tasked with building a brand new core banking engine and a kyc engine. I talked to the existing tech team that was there and none had ever done anything complex. Mostly they just knew how to write some basic PHP pages to do some simple tasks like rendering a CSV table for a specific report etc... So they needed to first be trained.
To cut a long story short I was the only one on the team to be able to write productive code to build such a complex system. I hired someone who could write code to help train the existing team. However given the complexity of the problem and the tight timelines I had to solve. I basically did the design and implemented about 70% of the code myself while my other teammates were being trained. This also included building a KYC engine along the way. I remembered suffering immensely building the engine and hiring / building the team. I would focus on working with the team during the day and coded at night, since that was the only time I could get un-interrupted hours to code.
I worked til 2AM almost every night for 7 days a week for over a year (6 months to get it to launch and then refinements / continuous improvements after). To complete the engine and get it to serve hundreds of thousands of transactions every month. I was never paid for overtime. Today the company stands strong with handsome profits.
Trust me. I can tell you, the problem is not the developers / process / agile / kanban / etc..., the problem is management. It's always management. I was able to get management to understand the true scope of the task by stopping working overtime and standing my ground (when the company had recovered and was able to produce a stable income to support itself).
The overtime I did hid away all the 'complexities' and the 'debt', and prevented the company from learning. I basically ended up paying for the company's mismanagement / toxic culture with my time. Fortunately a lot of toxic people left the company, a growing company will generally push out the non-performers organically. It took a lot of effort on my part personally to resolve issues plaguing the company, establish an engineering culture, build a strong tech team that can withstand pressure and deliver continuously and can build on top of the framework I provided.
The lesson has always been. It's never the software team (at least never the team I manage) whom are not productive or doing their best. It has always been management / company culture / never truly understanding the scope / requirement enough to understand how huge of an undertaking a given project is. I can tell you without a doubt this article pretty much hit the nail on the head. I'm living proof and have the battle scars to prove it.
Now I tell management about time estimates as it is. "No fixed timeline, the team estimate, the team builds, it's done when it's done, live with it or fire me."
I've fortunately afford myself the position to be able to deliver the truth serum to management and they have no choice but to accept it. It didn't come cheap, I'm still scarred.
For example, we had to reverse engineer something that a vendor provided. The vendor simply provided a binary that was executed and provided some kind of output. Including the binary into our build was one solution but it was not ideal since it meant we had to install another dependency that was old and outdated (java 6). So the other solution was to replicate this in our own native language (Elixir).
When I throw that kind of work at my team, more often than not I'll get a "not possible" as an answer.
Me being me. I took matters into my own hands. I reversed engineered the binary and was able to re-construct the logic and re-wrote the thing myself in our programming language and incorporated it into our pipeline flawlessly.
Sometimes you just need to get your hands dirty.
Or sometimes you are tasked with something innovative and having the ability to code at least gives you a chance to explore things and come up with a first draft solution which you can hand over to your team to fully bake.
Coding is an essential skill and teaches you to think in ways you can't possibly think otherwise (at least for me).
If you don't code and claim you are good CTO. Well how would you know you haven't coded you cannot compare how you would do if you knew how to code. So the assessment is not a fair test.
Now someone who has coded 20 years of their life becoming a CTO but CHOOSES to abstain from coding to focus on other areas. That's someone I would be interested to learn from.
It also gave me incredible sense of achievement. What I can say is I'm getting older now and I can say that my body ain't the same as I was when I was in my 20s.
Enjoy it while it lasts!
You really need to present well and be careful about arguments like “millions of websites use GTM”. I did days of research and presented that while yes using GTM on Wordpress sites that hold no sensitive data might be fine however we are a financial services and we collect customer private data. So getting everyone on the same page and presenting alternative ways of solving the problem was critical.
But again, since it's not always easy to find the right people I end up having to fill in for everything we don't have a team member to execute on.
Usually I try to reason with management first. If it can be resolved internally we would not include outside consultants, however if it gets serious beyond something we can handle internally we would ask outside consultant to come in.
Hiring people is difficult as there is lack of supply of talented people. We hire InfoSec on contract basis not full-time and they don't join such meetings due to the nature of the contract. So all the responsibility fell on me to defend our technical decisions at that point in time.
I'm working on building out the engineering culture / awareness within management now, to ensure these things do not happen, and I don't have to be questioned as to why we cannot install "google tag manager" in our front-end.
It all comes down to creating awareness, and making people understand. Fortunately for me our CEO gets it, he ended up siding with me.
I had to fight hard as an engineer to make sure that it does not happen. We had meetings after meetings, and it took a lot of effort for me to explain the risk of data leakage. I was questioned on my "insecurity" for not "trusting" people. It was not a nice experience. I had to inform them that tracking needs to be dealt with properly, not just lazily install google tag manager because it gives marketing 'flexibility'.