AI is incredibly powerful and it is relatively easy to add a rudimentary integration to new and existing software. It’s easy to get caught up in the hype and see every problem as solvable with an AI hammer.
But just because you can, doesn’t always mean you should.
Don’t get me wrong, I use AI-augmented tools every day and am amazed at what they do for my productivity. I also create AI-augmented features in the software that I build.
However, if I reach for the LLM AI “hammer” first, I bypass the opportunity to achieve better results and user experience. By focusing on the root problem at hand and structuring my data a bit better, I could nrgate the need for AI and achieve better outcomes.
For example, if your software needs to match job seekers with job specs, you could reach for the AI hammer to do the work, but you don’t need to. Why? Because AI yields “poorer” quality results than getting human assistance breaking down the constituent parts of a user profile and the parts of the job spec into structured data, matching these structured pieces, and human oversight to make the final judgement on a ‘good’ match.
For example, if your software needs to generate a list of similar job titles to one listed in a job post, you could reach for the AI hammer to do the work, but you don’t need to. Why? Because it might be cheaper, quicker and yield adequate results using existing databases like the US O*Net database of careers and salaries.
The point is, AI can do many things, but it’s not a panacea. You might find you get better results by exploring the root user problem and structuring new or existing data to solve the problem more accurately.
In the previous post I outlined why Supabase, Vercel & Svelte make up my current ideal technology stack. This post delves deeper into Supabase and why it has helped me fall in love with full-stack development again.
What is Supabase?
Supabase is a managed service which encompasses (but is not limited to) all of the following: authentication, database, file storage & serverless functions.
Supabase is like other “backend as a service” (BaaS) offerings like Firebase, but with a few notable differences; the project is open-source & is centred around an open-source relational database (Postgres).
What makes it so useful?
As I have lamented in the past, app development is complicated. Anything that reduces stack complexity can help focus developers on the things that really matter.
I tried Supabase for a weekend project for a local charity and achieved so much in a single weekend that I would consider myself an advocate for the product.
Following that experience, I have now used Supabase successfully for two additional production projects and plan to use it in the future for similar scenarios (small team startups).
Creating a relatively simple app over a weekend is not a huge accomplishment. There are other services and no-code platforms that can do something similar in the same timescales.
However, experience has taught me to get into the weeds with a product and then extrapolate into the future to gauge the real value of a tech stack. Low code and no-code tools are great, but at some point, in a growing project, you will hit a wall.
What makes Supabase stand out is that coupled with other developer tools like Svelte, it can be at least as productive as no-code tools without the drawbacks e.g. vendor lock-in, limited customization, up-front costs and scalability.
Embracing Open-Source and Community
My gravitation towards Supabase is also influenced by its open-source ethos which promotes transparency, collaboration, and community-driven innovation.
Being open to open source is more than just being idealistic, it’s also pragmatic.
The Supabase project is open source e.g. the code that runs its managed service can be downloaded and used on a server of your choosing.
If Supabase decides to increase the managed service cost to a level where it no longer makes sense to use it, you can manage the services yourself elsewhere.
Supabase has been completely transparent about its open-core business model from the start, hopefully, this model continues to work for them.
However, relying on open-source projects is not without potential pitfalls, especially when open-source companies’ heads get turned by greedy VCs and start over profiteering.
However, even though open-source licences can change, it is still better than the closed-source alternative where you are completely at the vendor’s whims from day one.
Simplifying the Complex
Creating apps is a complicated process even without having to worry about managing servers.
Delegating responsibility for managing auth, database, and storage to a managed service allows small teams to concentrate on more impactful concerns.
Not only does Supabase take these concerns away from you but it does it all in an easy-to-use dashboard.
The developer experience in general has been, dare I say it, enjoyable.
Using the Supabase tools and libraries has successfully reduced the complexity and lines of code in my apps.
The Security Model: Easy to Understand
The simplicity of the row-level security model in PostgreSQL is easy to configure and understand.
It presents a straightforward yet robust framework that drastically reduces the risk of misconfiguration—making security accessible to all of the team, even for newcomers, from day one.
However, it’s not perfect.
I have had experience in the past with different approaches to securing data. My least favourite way in the past was to implement the security rules totally in code i.e. lots of if/then statements hidden away in code that only the core developing team could understand or change.
In contrast, in my opinion, the “best” way I have experienced is to use declarative authorization rules, defined in the data schema e.g. Amplify authorization rules.
In the example below, any user can read from the “Todo” table/graphql type, but only the person who created the row can update or delete their own data.
## Configure schema and auth rules
## in one place
type Todo
@model
@auth(rules: [{ allow: public, operations: [read] }, { allow: owner }])
{
content: String
}
## Implementing something similar
## using Postgres/supabase
create policy "Allow select, update and delete for users based on id" on "public"."Todo" as permissive for all to public using ((auth.uid() = id));
create policy "Read for all users" on "public"."Todo" as permissive for select to public using (true);
It would be great if Supabase could cater for the type of declarative security as above, if anyone knows if it can, please reach out.
Scalability and Performance: Meeting Tomorrow’s Needs Today
In the past, I have spent countless hours trying to eek out marginal gains in performance in case my app goes viral. Spoiler alert… it didn’t… and I’ll never get those hours back.
Let someone else (with probably more expertise) obsess about performance and scalability.
Supabase’s seamless scalability ensures that as you grow, your backend does too—smoothly and reliably. This peace of mind allows you to focus your energies on innovation and enhancing user experience, secure in the knowledge that your technological foundation is a given.
The Cost-Effectiveness of Dreaming Big
In the world of startups, where every resource counts, Supabase’s pricing model is perfect.
The free tier is generous enough to battle-test your idea. The follow-on tiers are predictable and fair.
It’s not just about infrastructure costs where Supabase shines. The comprehensive savings in developer hours it enables through its exceptional developer experience is significant.
In my career, I have used other back-end-as-a-service offerings and Supabase compares favourably for the projects I’ve been doing lately i.e. small team startup.
My advice, if any is needed, is to look at your particular situation and try out any or all of the tools above on a pet project.
The “try out” part is key, all these sites have wonderful marketing websites which promise the earth. It’s not until you get down into the weeds on developer experience and pricing that the suitability becomes clearer.
*this post is the 2nd of a 4 part series of posts exploring Supabase, Vercel & Svelte. This post goes deeper into Supabase
Writing code is an inexact science, imperfections in your code are inevitable and add up.
Having a tool that constantly nags you to strive for perfect code is a must have for flawed [see human] developers.
Compiled Code
Where code analysis tools really excel is with compiled code.
With compiled code, the clean code tools not only analyse the quality of your code but also automatically fix and style it!. With compiled code you get piece of mind when these ‘automatic’ changes are made because the compiler is there to reassure you.
Thank God for Resharper!
I use these type of productivity tools religiously; in particular, for any C# or JS code that I write, I always use/need Resharper from JetBrains.
Some people might say that it is ‘lazy’, letting a productivity tool ‘automagically’ do what you should be doing out of hard learned habit. I agree, it is lazy, and I am often sloppy with my code knowing that my ‘magic helper’ will clean up after me. But, I have found that, after a while, I start incorporating the suggestions and changes that the tools give me into my ‘unclean’ code, so that the tools have less work to do and my code becomes cleaner ‘naturally’.
Too much of a good thing?
However, you can go too far with these tools.
Not only do you start to rely heavily on these types of tool to do a lot of the basic coding for you but also some of the suggestions it make for code changes can lead to your code becoming less ‘human readable’. It is soooo tempting to accept the suggestions to lambdify or linq entire sections of your code just because Reharper tell you to do it and it compresses your code to a single line. I thoroughly recommend watching the clean code Pluralsight course or reading Robert Martin’s (uncle Bob) book on clean code, to understand why human readable code is so important.
Interpreted Code
Things get more trickier with interpreted code e.g. Javascript. With interpreted code you do not have the compiler to reassure you that any ‘automagic’ changes are ‘safe’. For this reason, most clean code tools for interpreted code will give advice, rather than make changes for you. However, the ‘linting’ tools for interpreted code (JS in particular) have come a long way and are an essential part of any coder’s utility belt. For instance, when writing Javascript code I now rely [heavily] on Douglas Crockford’sJSLint to tell me that have been a naughty boy (I would highly recommend all Javascript developers to read Douglas’s book: Javascript The good parts and watch his talk on pluralsight) about Javascript.
What lint/analysis/style/refactoring tools do you use everyday and cannot live without? Leave a comment below:
Gone are the days for the software developer where you can learn one technology inside out, sit back and work at the same job for 20 years. Continuous learning, the ongoing voluntary pursuit of knowledge, is becoming an essential pursuit to most working in the software industry.
The technological landscape is evolving so fast that most of us programmers have to continually learn, or risk having an increasingly extinct set of skills.
There are a number of tools that I have started to use which have helped me better keep apace with some of the changing I.T. industry landscape.
Technical Podcasts – Learn On The Go
If, like me, you have a relatively long commute into work [30 minutes or more], there are many excellent ways that you can utilize this time. Some like to read newspapers, listen to music, enjoy a good novel; I like to use this time to ‘sharpen my axe‘ by catching up on the latest goings on in the software development world through listening to technical podcasts.
Using this time to listen to podcasts has been highly beneficial to me in a number of ways:
Learn the lingo. Once you start listening to podcasts you are much more aware and confident with many of the phrases and terms used within the industry. Terms like ‘big iron’, ‘cranking code’, ‘heisenbug’, ‘pokemon handling’, ‘stringly typed’ etc are all now part of a colorful vocabulary thanks to listening to others using them confidently on podcasts.
Bleeding Edge. Most of the podcasts pick up on new technologies or practices. If someone uses a brand new technical term in the office that starts you sweating that they will ask you your opinion on something that you cannot even spell… you can be sure there is a podcast for that.
Different Viewpoints. Going outside your comfort zone, like listening to web podcasts when you have spent your life as a desktop developer, will open your horizons to similar, but different ways, to approach your own field (you never know, you might pick up a new golden hammer).
General Consensus. As well as picking up new terms and technologies it also helps to reinforce current terms or technologies that you are already using.
Lots of Great Podcasts
Here are some recommended podcasts that I am currently listening to:
.NET Rocks : My favorite podcast for technical content. Excellent audio quality, content and banter. Not as Microsoft centric as you might think.
Hanselminutes : Again good content and quality but sometimes steers away from tech relevant subjects.
Herding Code. Great web podcast. Sometimes a bit Microsoft centric.
Javascript Jabber. Good for web/javascript technology talk. Sometimes a bit tangential but very enjoyable.
Stuff You Should Know : My favorite non-technical podcast. Good for some respite from too much tech talk. Josh and Chuck are very funny and present some dry topics in an entertaining way. Some great and varied subjects like ‘How Pinball works‘ to ‘How the scientific method works’.
What other resources have you come across?
Have you had any experience with any of the resources I have mentioned, what did you think?
For most of my career I have been a desktop developer but a few years ago I started making the move towards web development.
The move, at first, was horribly painful. For most of my working life I was working with the safety of compilers, full featured code libraries, mature test frameworks, UI frameworks and data-binding only to be thrown into the then (and even now) ‘wild west’ of web development.
My biggest gripe with web development was “how can it be so hard to do such simple things?”. I was finding that putting a button and some input controls on a screen that saved to a database required me to write waaaayyyy too much code. Never mind all the problems with screen size and browser compatibility, even simple things felt verbose and ‘hacky’
.
Silverlight – Desktop like, but flawed
I quickly retreated back from pure Javascript/HTML/CSS development to using something more ‘desktop-like’ and started using, and advocating, Silverlight.
Silverlight is [was] Microsoft’s attempt to replace Flash (more or less). Things were good, I was productive again and spitting out highly functional web apps until I started fully realizing the limitations of using a plugin based approach. On the brink of giving up web development due to frustration, I started looking at the latest web technologies that were beginning to gain some traction.
Knockout JS. Better, but still too many dragons to slay…
The first bit of relief came when I discovered Knockout.js. Knockout is a fantastic library that enables easy MVVM data-binding in your web apps. This was more like it, not having to write as much ‘grunt’ code to hook up data with UI felt much better. Something as simple as the data-binding that knockout gave me renewed my enthusiasm for web development and I started to look for other libraries that could address the other reservations that I had about web development.
Angular, now we’re talking
The next discovery, and most fruitful, was AngularJS.
Angular is a Javascript library from Google which makes web development sooooo much easier. For almost every problem that I started to ask Angular it seemed that the developers had already had the same pain and had already built the functionality into Angular already. If there was something that I needed from the framework that didn’t already exist, there was usually an Angular extension that was readily available or I was able to make a directive from an existing Jquery plugin.
Angular has become so much of a golden hammer for me that I find it hard to contemplate starting a large website without using it.
Looking to the future
The landscape for web development is evolving rapidly but with frameworks like Angular, and maturing and adherence to web standards, it does not seem as anarchic as it once was. There are several other libraries that have made my life easier such as underscore/lodash, twitter bootstrap, and breezejs, but the underlying library that has made the most difference is Angular. Since converting to Angular I am now a happy and more productive web developer. Before, I was extremely frustrated and unproductive and although Angular, and web development in general, is still far from perfect, it is a more enjoyable place to be.
A Word of Caution for Angular 2
Before you get carried away and start seeing everything in angular tinted glasses, you need to consider the ramifications of the upcoming Angular 2.0.
I have had a look at the 2.0 syntax and it is a big departure from 1.x. IMHO this is a strange and worrying decision from Google as many people looking to dive into Angular at this point in time will be uneasy that the code they write now will not be supported/current in the near future.
2 Golden Hammers?
Although promises of a clear upgrade path are promised by Google, it might be time to find a backup golden hammer (i.e. React) to hedge my bets.
Has anyone else got similar experiences with Angular? Have you found other libraries that you feel you cannot do without? How do you see the future for frameworks like Angular, React, Backbone or Ember?