12.5.24 
 
ChatGPT was released almost exactly two years ago. One year later, it had become the fastest-growing consumer software application in history. Another year later, and it is integrated into every new Apple product’s operating system. AI in general has become super important, super quickly. A lot of people, even outside of the dev world, are afraid that AI will take their jobs, and in most cases, it probably will. It is already starting to feel like you need to learn how to ride this bullet train or get left behind. AI hasn’t just made Siri smarter at editing the grammar in your emails; it has already transformed how most people work. AI has, of course, changed how people code and build software, but it has also become a part of the tech stack itself. 
 
Three to four years ago, I was really excited about neural networks and machine learning. Somewhere in the depths of my GitHub, there is a repo for a Python chatbot trained on Wu-Tang lyrics. Needless to say, I have been heavily tuned into AI and OpenAI and ChatGPT since its release. It’s funny how at first, using AI to help write some functions felt almost taboo; now it is completely expected. I have thought about writing a blog post about coding with AI, prompting, AI image generation, or maybe exploring some of the cool tech behind these new AI-powered apps, like LangChain, but I want to start by exploring the AI within the stack and how it is affecting and influencing the rest of the stack. 
 
Aside from the conversational LLMs, one of the first AI tools that I integrated into my tech stack was GitHub’s Copilot. It was pretty exciting when it came out - to have AI actually in your IDE instead of having to copy and paste snippets of code elsewhere. I read that a single dev created Copilot, which unfortunately might be the coolest thing about it. If I didn’t have a subscription through work, I would not have made it past the 30-day free trial. I really only found Copilot to be useful when writing very predictable and relatively simple code. I have heard that Copilot is a little better these days, but AI is already pretty far ahead of just completing functions for you. What Copilot and the copy and paste method always lacked was context. Even with the ability to upload a file, you still lacked context of your entire project. This is why I thought Cursor was going to be a serious game changer. <a href="https://www.cursor.com" style="color:purple;">Cursor</a> is essentially a VS Code clone that integrates an LLM of your choice — be it OpenAI’s ChatGPT or Anthropic’s Claude into your entire code base. Cursor is seriously cool. It has a conversational element, it has the prediction feature that Copilot has, it can review your code and fix your bugs and errors, and it can inject code directly into your project. Pretty wild stuff. Cursor operates like a subscription SaaS, with a flat monthly fee instead of using your own API keys, which is how most of the AI VS Code plugins previously worked. The flat fees are also pretty reasonable; they have a free tier, and the first premium tier costs $20 a month, which is pretty cool to have access to premium LLMs from OpenAI and Anthropic when those cost $20 a month each. Cursor might be the most comprehensive AI coding tool out right now, but OpenAI is already on track to making it obsolete. I don’t think it is even fully rolled out yet, but OpenAI’s new native app for Mac and Windows is pretty next level. You can now give ChatGPT access to VS Code, Xcode, and the Terminal/Command Line. So, the new ChatGPT app doesn’t just have the context of your code but your entire dev environment. 
 
This next part might feel a little funny coming off of the previous blog post. That entire post was essentially about how freeing it felt to step away from frontend component libraries, and I already want to talk about another one. TLDR; I wrote how Tailwind, with a little help from Framer Motion, has allowed frontend development to take some big steps forward by ironically getting back to the basics of the foundations of traditional CSS. AI being in your tech stack means it will inevitably influence the rest of the stack, which is how I started working with Shadcn UI. 
 
As Tailwind became the new standard in CSS, Shadcn UI popped up in a wave of other component libraries built on Tailwind. We now have Daisy UI, Mantine, Flowbite, Chakra UI, Oxbow, Preline UI, Flyon UI, Ripple UI, Sira, Mamba UI, Next UI, Kutty, Sailboat UI, Xtend… Exhausted yet? I have checked out most of these. For a couple of them, it was my actual job to become an expert in them… and the others were because I am a nerd? I’m not going to lie, some of these libraries look really cool, and being built on Tailwind is kind of exciting because you should be able to fully take control of them. However, a lot of my gripes with component libraries still hold true when using these. You are still using a third-party design system that will either have to be heavily customized or run the risk of looking recognizably stock. You obviously have to learn the libraries’ syntax and nuances. You also have to be careful about not bloating your app and increasing the build size with unused CSS bundles and extra JavaScript overhead. Sure, some of these component libraries support tree shaking, meaning only the components you import and use are included in the final build, but you need to look into the specific one you are using. I wasn’t using Shadcn UI at work or on personal projects, so when the hype really started to hit, I’ll admit that I had some real “Get off my lawn!” feelings about it, especially since it was built on yet another component library in the first place, Radix UI. So to use Shadcn UI, you need to learn two libraries (you don’t), you have to install each component via the CLI (spoiler: the shadcn CLI actually rules.), their website claims they aren’t actually a component library but clearly are a component library. I was not on board at first. 
 
What (or who) helped Shadcn UI cut through the noise of all the other Tailwind component libraries was Vercel. Vercel is a hosting platform and the team behind Next.js. Since acquiring the dev behind Shadcn UI last year, Vercel has been heavily integrating it into their ecosystem. The most significant integration has been with <a href="https://v0.dev/" style="color:purple;">v0</a>, Vercel’s AI-powered text-to-UI creator. There have been a ton of apps touting AI text-to-UI generation popping up in the last year or so, especially in the Tailwind world. They usually feel like fun novelties and ultimately of a waste of time if you know how to code, so I was not super quick to adopt v0. But Vercel is hard to ignore when Next.js is one of your main tools. v0 has been the first AI UI tool where it feels like you are cheating. You don’t need to be an experienced prompt engineer to have it spit out some pretty impressive code. It won’t completely knock it out of the park, but if you are down with Tailwind and Shadcn UI, you can take the v0 code as a really nice foundation to customize and build off of or just brainstorm. I don’t really want to get too deep into the weeds here with how to use Shadcn UI, and I won’t say something like “the hype is real” with it, but it is definitely worth exploring. Shadcn UI is extremely flexible, has been a huge time saver and has become a welcome part of my stack because of the influence of an AI tool. 
 
There are a ton of awesome LLMs out right now, each having their own strengths, but clearly the leaders of the pack and stars of the show are OpenAI’s ChatGPT and Anthropic’s Claude models. There are a few models from each out right now but for our context, the ones that matter are ChatGPT 4o and Claude Sonnet 3.5. For most cases these two are pretty toe to toe but there are some subtle differences. GPT 4o is a little better at zoomed in, low level, logic-heavy problem solving where Sonnet 3.5 has some better context retention for longer conversations and is a little better at high level architectural brainstorming and decisions. They are both prone to errors and need to be kept in line but there is a feeling that GPT 4o can go off the rails a little easier and will sometimes come across overly confident in the incorrect solutions that it presents. 
 
AI is no longer an experimental layer on top of development. It’s already woven into the fabric of the modern tech stack and will only become more important. From text-to-UI tools like Vercel’s v0 to IDEs like Cursor, to powerhouse LLMs like GPT 4o and Claude Sonnet 3.5, AI isn’t just assisting developers — it’s influencing and reshaping how we build. If frameworks like Next.js and Tailwind brought us back to the foundations of web development, AI tools are pushing us forward in a way that feels genuinely revolutionary. Coding with AI feels less like outsourcing your work and more like unlocking new levels of creativity and productivity. Getting on board with these tools really feels less like AI is replacing us but augmenting us. 
 
January 2025 addendum: 
Last month, just days after I published this blog post, GitHub Copilot announced a free tier and a revamped VS Code integration. It is so awesome that I actually felt obliged to update this and mention it. I don’t want to take my words back because five weeks ago, I was genuinely underwhelmed with Copilot and now it looks like Copilot is about to make Cursor irrelevant. Copilot went and took the best parts of Cursor, chatting with 4o or Sonnet 3.5 right in your IDE with full repo context with the ability to inject code, and the newest features of the native OpenAI apps which are the IDE and terminal integrations and offer it for free. On top of that, if you upgrade to a pro account you get unlimited completions, unlimited chat messages in the IDE and the ability to have Copilot in your actual terminal, in the CLI, get pull request summaries, and more. The kicker is a pro account is only $10 a month or $100 for a year, so it is less than half the price of Cursor and already so much more. Isn’t it wild how insanely fast this tech is moving?

large_aiblogheader.png

medium_aiblogheader.png

small_aiblogheader.png

thumbnail_aiblogheader.png

aiblogheader.png

AI In The Modern Tech Stack

8.26.24 

 
When I first got into web dev, component libraries like Bootstrap and Material UI were huge. I wrote a blog post comparing those two back in 2021 and while I didn’t mention it specifically, there is this implication that when developing with React, you should pick one of the two. Component libraries seemed to go hand in hand with React for a long time. These libraries had a specific aesthetic that felt nice and modern and they promised to save you from the tedium of building components from scratch. Basically, these component libraries looked cool and saved you time; win win. But after only a few short years, the aesthetic of some of these libraries started to feel dated and the reality set in that fully customizing them is not worth the headache. 
 
Bootstrap has been around for ages, and for good reason. It was a lifesaver for anyone looking to quickly build a responsive UI without needing to think too much about design. In hindsight, I think a lot of the popularity also came from people avoiding writing and learning real CSS. But with that ease came rigidity. You had to adhere to the Bootstrap way, and customization often meant fighting against its default styles. Material UI (MUI) brought some fresh air with a modern design system, but let’s face it, it could feel heavy and look super stock. Sometimes these out-of-the-box components don’t always align with the visual identity you want for your project. 
 
I think Tailwind has been a tremendously positive influence on frontend development. It brought people back to writing and understanding CSS. Tailwind doesn't give you pre-built buttons or navbars but you can piece together the exact design you want without installing or importing any additional tooling. The framework forces you to think about styling in a modular way, directly within your markup. This might sound messy at first (I still see people hating on it on reddit every day), but it actually promotes a clear separation of concerns. You're never left wondering which CSS file to dig into when you want to tweak something. 
 
More modern component libraries like DaisyUI, ShadcnUI and NextUI are now built on top of Tailwind CSS. They give you more control and less baggage than Bootstrap and MaterialUI. Working with these Tailwind component libraries definitely feels like a big step forward. Yet, as convenient as it is to have pre-built components, it doesn’t take long before you start to run into the same old walls: inflexible design patterns, inconsistent animations, limited components (you can but really shouldn’t mix and match these libraries) and the general sense that you’re still working within a box someone else designed. 
 
Ok, let’s talk about Framer Motion. Framer Motion is an animation library designed for React that is made by Framer, which is a no-code website builder. I have never actually used Framer but I have a lot of experience developing with Webflow, which looks like Framer’s direct competitor. Framer Motion makes it incredibly easy to implement complex animations with pretty minimal code. Need a subtle fade-in on a component? A spring animation on page transitions? No problem. Framer Motion gives you all the tools without needing to deal with the tangled mess of traditional animation methods. 
 
But here’s where the magic really happens, Framer Motion plays really well with Tailwind. Tailwind handles the initial CSS, while Framer Motion injects that dynamic energy and smooth interaction we’ve come to expect from modern web experiences. React, Tailwind, and Framer Motion aren’t just great individually, they complement each other perfectly. React lays the groundwork with its component-based architecture, allowing for modular and reusable code. Tailwind provides the design freedom to build exactly what you want, how you want it. And Framer Motion breathes life into your components, making them feel dynamic and responsive in a way that few other tools can. 
 
With this trio, you’re not stuck in someone else’s design system. You’re not locked into their opinionated choices about how animations should work or what a button should look like. You’re free to create, iterate, and animate at will—without feeling like you’re hacking around arbitrary restrictions. I have truly found this combo has allowed me to avoid all pre-built component libraries. Component libraries are traditionally great for things like accordions, modals, navbars, etc. and using Tailwind and Framer Motion together, I have been able to create all of these from scratch without adding to the bloat of my projects. This trio of React, Tailwind and Framer Motion hasn’t just allowed me to stop using component libraries, it has allowed me to stop using third party libraries for things like toast notifications as well. 

 
Component libraries have their place — they’re great for getting something up and running quickly, especially if you’re not too concerned about the uniqueness of your design or the fluidity of your interactions. But for me, the combination of React, Tailwind CSS, and Framer Motion offers an unparalleled level of control and creativity. 
 
It’s the freedom to design without constraints, to animate without limits, and to build exactly what you envision—no compromises required. If you haven’t tried this combination yet, I highly recommend giving it a go. You might just find yourself, like me, reluctant to return to the world of pre-built component libraries.

large_24-frontendmagictrio.jpg

medium_24-frontendmagictrio.jpg

small_24-frontendmagictrio.jpg

thumbnail_24-frontendmagictrio.jpg

24-frontendmagictrio.jpg

Magical Frontend Trio: React, Tailwind, and Framer Motion

7.23.24 

 
A little over a year and a half ago, I wrote a <a href="https://www.adamhunter.website/blog/19" style="color:purple;">blog post</a> exploring BaaS (Backend as a Service) platforms. I chose three popular ones: Google’s Firebase, Supabase, and AWS Amplify. Technology changes so fast these days, but these three are still relevant and top choices for many developers. In the engineering world, AWS is a big deal. Most hosting providers and services typically just use AWS under the hood anyway, so I always thought it made sense to skip the middleman and do it yourself. I have been using AWS services for a long time on professional and personal projects, and I really wanted to like Amplify. Unfortunately, it ultimately proved to be a little frustrating and limiting, so I concluded that using AWS services à la carte is probably the way to go. 
 
I was also attracted to Supabase for a few reasons. It is open source, which is very cool. You can self-host Supabase if you want to. A big one for me was the fact that the database is PostgreSQL. I have traditionally been under the impression that most data is relational and that you should always default to SQL databases. I thought MongoDB and the MERN stack were more or less for the YouTube and bootcamp crowds. Fun fact: working on a professional project using AWS DynamoDB, which is NoSQL, helped me change my tune and open up to NoSQL. 
 
I make no secret of my preference and fondness for Next.js. The Next.js community does seem to have one gigantic sticking point though, that causes endless debates and has spun off tons of third-party applications to try and solve authentication for Next.js applications. Auth.js, or Next-Auth (depends on who you are talking to), is a pretty solid option where you can sort of roll your own auth and use whatever database you want. It can also act as a middleman to other auth services. Auth0 is an awesome option if you can afford it. Clerk is a newer solution that I see being used a lot more in the wild lately. Nobody loves AWS Cognito (looking at you, Amplify). Staying in the loop with the Next.js community, I started noticing people recommending Supabase and Firebase just for their auth systems. Full circle. 
 
I recently had the opportunity to work on a greenfield MVP, and all signs were starting to point to Firebase. Spoiler alert: I am now a big fan of the platform and have even created an <a href="https://github.com/Adamhunter108/next-firebase-starter" style="color:purple;">open-source boilerplate starter</a> for using Firebase with Next.js. Feel free to check that code out as an example or even fork it and use it for your own project. In addition to the obvious technologies, I also included Zustand for state management and to help with the auth by setting a cookie. In addition to fully fleshed out auth pages, I included protected pages to manage user account data as well as a posts section to demonstrate accessing public data. 
 
Let’s start with the auth because that's how I came back to Firebase in the first place. In order to use Firebase Auth, you need to install the SDK. After a simple npm install and setting environment variables in your firebaseConfig file, you now have access to an extremely reliable and secure authentication system. It uses JWT under the hood, which should be familiar to most devs, but it handles the creation, storage, and refreshing of tokens for you. They offer pre-built UI components for their auth, but you also don’t have to use them, which is awesome. Sometimes trying to customize pre-built auth components can be a big headache. While it’s nice creating and coding with the Firebase SDK for auth, your boss will like it too. This is a Google product, so the user analytics tools available are extremely comprehensive. You can track and monitor specific user engagements, page retention, conversions, create custom audiences, get behavioral insights, feature usage, user flow analysis, real-time custom reports, etc.; all on top of security and monitoring features like fraud detection. Yes, you do end up with some vendor lock-in by using Firebase Auth, but at least you know Google isn’t a startup that won’t be around next summer. 
 
After auth, the next star of the Firebase show is Firestore. Firestore is a serverless, cloud-based NoSQL document database. There is a reason that startups and solo devs love serverless architecture: money (of course). With serverless architecture in general, your costs should only go up once your app's usage is up, so you don’t have to pay for resources you aren’t using yet or may never need. Firestore will automatically scale up and down based on your app's usage. 
 
In addition to the serverless architecture and automatic scaling, Firestore comes out of the gate with real-time data capabilities. This was also a big point of concern with the greenfield MVP because we needed to build a live chat feature. While real-time data can be achieved with most databases, it is usually pretty complex and requires additional resources; for PostgreSQL, you would need message brokers like RabbitMQ or some sort of additional WebSocket server. Firestore uses listeners to monitor changes in data. When a document changes, a snapshot is sent to the client, providing the updated data immediately. This is done using WebSockets, ensuring low-latency updates. 
 
Regarding the live chat feature specifically, we explored some other popular options. There are companies, services, and APIs that help small teams and startups build real-time data apps and tools. I’m going to name-drop a little. Three popular ones are SendBird, PubNub, and Twilio. SendBird lets you get started with 100 MAU (monthly active users) for free and then jumps up to $400 a month for 5k MAU. PubNub gives you 200 MAU for free and then jumps to $100 a month minimum for a pay-as-you-go plan. Twilio also gives 200 MAU for free but then jumps to $0.05 per user up to 5k users and then $0.475 for up to 10k MAU. That's $475 a month for 10k users. An estimate for 10k MAU using a live chat feature built with Firebase is about $15 a month. 
 
The next big feature in the Firebase ecosystem is Storage. Storage is where you store and serve media content like videos and images. I found Firebase Storage to be pretty comparable to AWS S3 Buckets. The same way S3 integrates well with other AWS services like Lambda, RDS, etc., Firebase Storage obviously plays really well with all of the Google varieties. I would say developer experience is quite similar. AWS uses IAM and bucket policies, and Firebase Storage uses security rules. Storage will also automatically scale and has pay-as-you-go pricing. Firebase Storage also leverages Google's global CDN (content delivery network) to deliver files quickly and reliably, regardless of the user's location. 
 
Firebase provides a comprehensive suite of tools that are particularly suited for modern web and mobile application development. Its robust authentication system, real-time database capabilities, and flexible storage solutions make it an awesome choice for developers. The ease of integration with other Firebase services and the cost-effective scaling options just crank the appeal. Whether you're a startup looking to quickly develop an MVP or an established company seeking reliable and scalable backend services, Firebase offers a powerful, user-friendly platform to build upon. If you're interested in trying out Firebase, check out my <a href="https://github.com/Adamhunter108/next-firebase-starter" style="color:purple;">open-source boilerplate starter</a> for a head start on your next project.

large_23-rediscovering-firebase.jpg

medium_23-rediscovering-firebase.jpg

small_23-rediscovering-firebase.jpg

thumbnail_23-rediscovering-firebase.jpg

23-rediscovering-firebase.jpg

Rediscovering Firebase

3.20.24
 
I started to write a blog post about the JavaScript framework Astro. I still might, Astro is very cool. It has very recently become an official full-stack framework since they launched AstroDB, which is a fully managed SQL database. At first, this might sound a little weird coming from a framework that seemed to boast a bare bones ethos. Astro claims to be a content driven web framework and can strip away all of the JavaScript from the final build of a website, even if you choose to build it with React, for performance and SEO. In Astro’s attempt to allow devs to build anything, AstroDB seems to be a very welcomed feature to the ecosystem, but this is another example of a point I see raised pretty often in both positive and negative contexts; that in web development, there is no such thing as a “frontend developer” anymore. 
 
Every now and then I’ll see a thread pop up on a web dev subreddit where somebody has been a frontend dev for a long time and either out of necessity or curiosity will explore the modern frontend world outside of vanilla HTML, CSS, JS (and usually PHP) and will be overwhelmed by how much more frontend devs are expected to handle compared to say ten years ago. One of the first hurdles I notice, especially in the React world, is state management. 
 
Application state essentially serves as the foundation for dynamic content in UIs. The state is responsible for interactive elements that respond to user inputs, real-time data updates, and other asynchronous events. As applications grow in complexity, managing state can become crucial for having both a smooth UI and honestly, a smooth developer experience. Almost three years ago, I wrote a <a href="https://www.adamhunter.website/blog/4" style="color:purple;"> blog post</a> on Redux, which at the time was the defacto industry standard for state management in React apps. The blog post is still relevant, the only thing that has changed is the fact that Redux is not the default go-to library anymore. Some newer and exciting options have popped up over the last few years including Jotai, Recoil, the native Context API, and my personal favorite Zustand. No matter which state management tool you go with, you will have to balance the pros and cons of the different libraries with the syntax of actually coding with these different tools. This also means understanding component state lifecycles and data flow which means having an architectural mindset that was traditionally reserved for backend development. 
 
Sticking with React, which is where most of my professional experience and personal preferences lie, there has also been a pretty significant shift in the last few years away from client side SPA’s to full-stack frameworks like Remix and Next.js. Remix is a full fledged React full-stack framework (now owned by Shopify btw) with templates that come with all the bells and whistles of a Postgres database, authentication, testing and more with the ability to render React components either in the client or on the server. Next.js is a little different… it is a full-stack framework… but it’s also not, but kind of is, or kind of can be. Next.js is a little more nuanced and one of the features that has made Next.js so important and a little ambiguous in qualifying it as a full-stack framework is its serverless API routes. The Next.js serverless API routes essentially give you the power and serverless architecture of something like AWS Lambda right in your frontend; which for many use cases, lets you move away from the need for a traditional backend. Does that make Next.js full-stack, it’s debatable, however, installing an ORM like Prisma to a Next.js project to directly communicate with a database definitely does. 
 
If you are using Remix, Astro or Next, you also have to understand the difference between writing client-side and server-side code and how it impacts hydration. The most recent version of Next.js has actually made it a server-side first framework, which is a little strange for a JavaScript framework. JavaScript has traditionally been a client-side scripting language for a really long time. Now, if you are creating a component that does not require server actions, you have to explicitly tell Next to “use client”. Fully server-side React code definitely has some cool advantages that include SEO and initial load times but for a lot of dynamic interactions that don’t require a fresh page from the server, client-side rendering can make the UI feel more responsive and fluid. 
 
At first glance, these full-stack frontend frameworks, such as Next.js, might seem like they're retracing steps back to the more traditional full-stack frameworks like Django for Python and Laravel for PHP. However, Django and Laravel both follow server-centric MVC (Model View Controller) architecture where Next.js does not. Beyond simply enabling the use of React for the frontend, Next.js introduces a level of flexibility that proves to be pretty advantageous, not only in terms of the developer experience but also for developing scalable, microservice oriented applications with a more modular approach. They also play great together, you don’t have to choose or sacrifice using tried and true Django or Laravel as your backend to use Next.js on the frontend. In fact, using Next.js as the frontend framework with a traditional backend is still very common and super powerful. 
 
Whether you are working on a traditional agile team of cross-functional frontend and backend devs, or a general web dev hobbyist, chances are you will have to dip your toes in tasks across the entire stack. For this very blog post, I had to recently migrate from an old database and created and provisioned a new Postgres database with a Node.js application serving API routes to display this in my website which is a Next.js application. These posts are also server-side for SEO and speed. That definitely sounds a little beyond traditional frontend to me. I’m not posing all of this to say that frontend is better or harder than traditional backend development, it’s actually the opposite. I love both and think those who love this stuff will inevitably be drawn to both. Being a full-stack developer means you can build anything, which is why I learned how to code in the first place. I’m psyched to see what the next several years look like for all of these awesome tools. Maybe I’ll even write that post on Astro.

Closing the gap between frontend and backend

large_22-frontendbackendblur.jpg

medium_22-frontendbackendblur.jpg

small_22-frontendbackendblur.jpg

thumbnail_22-frontendbackendblur.jpg

22-frontendbackendblur.jpg

Frontend & Backend Blur

11.22.23
 
Most people, even outside of web dev, usually have a high level understanding of what CSS is. It’s the code that makes HTML look cool. I have heard the analogy that if a web site was a house, that the HTML would be the wooden frames, JavaScript would be the plumbing/electric and CSS would be the paint. The truth is that CSS is more like the foreman. CSS describes how elements are rendered on the screen. 
 
CSS is more than just colors. CSS is also responsible for the layout, which includes making pages responsive (looking good on all screen sizes). CSS can also handle animations and even interactivity. CSS is way more complex than most people give it credit for, especially when you really deep dive into all of the pseudo selector classes. You can do a ton with just HTML & CSS and make things look awesome.
 
But CSS is also the paint. CSS is definitely responsible for colors and to be honest, they can be a little weird and deserve some explanation. Sticking to just the colors, I want to dig into the main color formats that you have available in CSS. 
 
The first and most obvious one being the Named Colors. HTML and CSS come stock with 140 colors that you can use. 140 colors feels oddly specific and also kind of limiting, doesn’t it? There are some pretty weird ones on the list like IndianRed, AliceBlue, LightGoldenrodYellow, OldLace, Peru… the list goes on. The thing is, aside from having slightly racist and kind of random names, the colors themselves are actually kind of a mess. The standard 140 colors that we have today come from a mishmash of sources going back to the Unix X11 X Window System, which celebrates its 40th birthday next year, to HTML 4 spec which is now 24 years old. How old the colors are really doesn’t matter, what matters is that despite a few attempts at standardization, the colors are still super inconsistent. The most common example is that <code style="color: green;">Gray</code> is darker than <code style="color: green;">DarkGray</code>. 
 
I’m not hating on the named colors. Nobody is mad about <code style="color: green;">background-color: black;</code>. Named colors are awesome for writing some fast code, showing an example or using as a placeholder. 
 
Not limiting yourself to the 140 named colors, you can use RGB (Red, Green, Blue) colors. Over 16 million colors can be represented by RBG. You can’t represent the entire spectrum of color perceived by the human eye but you can represent the full spectrum that modern screens can display. RGB values are actually based on the physics of light. In addition to the slightly expanded color palette, RGB colors are super consistent because they are represented by numeric values. 
 
The way RGB works is by determining how much of each color is mixed in. The colors, called channels, can be given values from 0 to 255. Put all values at 0, you have black. Put all values at 255 and you get white. Crank just the first one to 255 and leave the rest at zero, rgb(255 0 0), and you get red. With CSS you can actually use percents instead of the 0 to 255 system, but this is a little less common. 
 
Along with the RGB color channels, CSS also allows for adding the alpha channel. Sometimes called RGBA, the alpha channel is used to indicate different levels of opacity. The alpha channel ranges from 0, fully transparent, to 1 which is fully opaque. Use it in CSS like this: rgb(255 0 0 / 0.5). That makes a 50% transparent red. 
 
The next color format I want to get into is Hexadecimal. Hex is probably the most commonly used color format in web dev and my personal preference. Hex syntax is the easiest to copy and paste and it is the most concise. Hex is also the default color format in some UI design tools like Figma. Hexadecimal is essentially the same as RGB with different syntax. So you get the same 16 million plus color palette. 
 
With RGB you just have the 3 values, in the Hex format you define your colors by RRGGBB (6 values = hex). The values go from 0-9 and then A-F. Hex colors are also always defined with a hash (#) in the beginning. So to get red, you crank the first two values to F, #FF0000. 
 
Another cool thing about the Hex format is that you can go Octodecimal. Jk I don’t think anybody calls it that, but you can add an alpha channel value right onto your Hex color to play with opacity. No special syntax is required for the alpha channel on Hex colors, just add it at the end like this, #FFFF0080. 
 
RBG and Hex have essentially global browser support, even with alpha channels. CSS actually supports a ton of other color formats too. The next being HSL (Hue, Saturation, and Lightness). The theory behind this color format is that it is supposed to be a more human way of determining colors. The syntax for HSL looks a lot like RGB. The same red that we have been using as an example, with the alpha channel, looks like this in HSL: hsl(0deg 100% 50% / 0.5). First the hue is defined on a circular scale from 0deg to 360deg, then saturation and lightness are defined by percents.
 
You can keep going too, CSS supports five more formats including LCH (Lightness Chroma Hue), which is very similar to HSL, OKLAB, OKLCH and Display P3. These are all more modern and they also attempt to define colors in more human and intuitive ways. Honestly though, I have never used these and seeing them in the wild is kind of rare but it is cool to know they exist. 
 
As I mentioned earlier, most graphic and UI design tools use either RGB or Hex colors. Most color pickers do too. Just Google “color picker” and you can see Hex, RGB, CMYK, and HSL in action. If you are on a Mac, you actually have a pretty awesome app pre-installed on your computer called Digital Color Meter that will show you RGB and Hex color values for anything you hover over with your mouse. You can even copy and paste right from there. 
 
To close this out, I want to mention that if you are now sad at the suggestion that you shouldn’t use the stock named colors, you can always define your own named colors using Hex or RGB in the scope of your project using CSS variables! Technically this is called CSS Custom Properties but is usually referred to as CSS variables. More good news, you don’t even need a fancy CSS framework like Sass or Tailwind to do this. 
 
Thanks for taking this deep dive into CSS colors with me. CSS is awesome and I love nerding out about it.

large_21-csscolors.webp

medium_21-csscolors.webp

small_21-csscolors.webp

thumbnail_21-csscolors.webp

21-csscolors.webp

CSS Colors

5.17.23
 
Google Sheets and/or Microsoft Excel spreadsheets are industry standards for data management, financial analysis, presentations and reports, project management (Google Sheets actually makes a great scrum board) and general organization. Be it Google Sheets or Excel, these spreadsheets have been an integral tool for every job I have ever had. Even though Microsoft now has Excel Online which works the same way as Google Sheets, being able to access and edit your spreadsheets from any web browser, Google Sheets still has the huge advantage of being totally free. You can’t really beat just typing <code>sheets.new</code> into any browser to have a fully functional and collaborative spreadsheet. 
 
On top of the aforementioned uses for Google Sheets, there are some creative ways developers are using it including using Google Sheets as databases for web apps. Through the use of APIs, you can programmatically perform CRUD (create, read, update, delete) operations on the data in a Google Sheet. Let’s break that down a little. That means having a database with the comfort zone UI of an Excel spreadsheet that can be shared with other users. You will also have real-time updates and not have to worry about infrastructure management such as maintaining database servers and creating backups. Since this is Google, another nice thing about this is the integration possibilities. Google Sheets plays very nicely with a myriad of other tools for automation and extended functionality within the Google ecosystem. 
 
You knew this was coming, the disadvantages of using Google Sheets as the database for your app. Off the bat, Google Sheets is not an ACID compliant database which would make it illegal in certain specific cases. There is practically no scalability because it’s not designed to handle large datasets or heavy traffic. You are obviously locked into the spreadsheet tabular data structure which also means you can’t perform complex queries, manipulation or aggregation. 
 
So using Google Sheets as the primary database for an app seems a little impractical, but using it for a specific feature like using it with contact forms can be very cool. Google provides an officially supported Node.js client library for accessing Google APIs that you can pretty easily integrate into a Next.js project. One of Next.js’s core features is the serverless API routing system. This is what makes Next.js feel like a full-stack framework. A Next.js serverless API handler means you don’t need a traditional backend server running and the code will only execute when you need it to. Using a Next.js serverless API with Google Sheets means this feature will have no extra costs to maintain. Google Sheets also has a cool feature that can email the users of the spreadsheet when new data is entered (or changed) which means you can even skip integration with a third party email provider like SendGrid. 
 
I’m not going to turn this into a full blown tutorial but I will share how it is done and the core code to make this work. If you are totally unfamiliar with GCP (Google Cloud Platform), feel free to email me for some help. Otherwise in your GCP console, you will have to enable the Google Sheets API, create some credentials, create a service account, and create some API keys. You will also need the specific spreadsheet ID which is the part of the url that comes right after <code>https://docs.google.com/spreadsheets/d/</code>. You will also need a frontend form component that is sending a POST request to your serverless API route. For stuff like this I usually like to use <code>react-hook-form</code> for validation. Once your form is set up, make sure you <code>npm i googleapis</code> to install the Google Node.js client library. Then in the API directory in the Next.js project, drop this code in. 
 
```javascript
import { google } from 'googleapis';

export default async function handler(req, res) {
if (req.method === 'POST') {
const { Name, Email, Subject, Message } = req.body;

 const auth = new google.auth.GoogleAuth({
 credentials: {
 client_email: process.env.GOOGLE_CLIENT_EMAIL,
 client_id: process.env.GOOGLE_CLIENT_ID,
 private_key: process.env.GOOGLE_PRIVATE_KEY.replace(/\\n/g, '\n'),
 },
 scopes: [
 'https://www.googleapis.com/auth/drive',
 'https://www.googleapis.com/auth/drive.file',
 'https://www.googleapis.com/auth/spreadsheets',
 ],
 });

 const sheets = google.sheets({
 auth,
 version: 'v4',
 });

 const response = await sheets.spreadsheets.values.append({
 spreadsheetId: "YOUR SPREADSHEET ID",
 range: 'Sheet1!A2:D', // The range of cells where you want the data entered.
 valueInputOption: 'USER_ENTERED',
 requestBody: {
 values: [[Name, Email, Subject, Message]],
 },
 });

 res.status(201).json({ message: 'Data successfully entered to google sheet', response });
} else {
 res.status(200).json({ message: 'Success' });
}

}
```
 
Don’t forget to set up your local development and production environment variables and put in your own spreadsheet ID. 
 
You can customize this approach pretty easily for other use cases. If you don’t like the contact form idea, this can also just as easily be a cleaner and more professional way to integrate Google Forms for any data intake such as surveys or event sign ups.

Send data to Google Sheets using a Next.js serverless API route

large_20-nextgooglesheets.webp

medium_20-nextgooglesheets.webp

small_20-nextgooglesheets.webp

thumbnail_20-nextgooglesheets.webp

20-nextgooglesheets.webp

Next.js and Google Sheets

1.25.22 
 
A Backend as a Service (or BaaS or mBaaS if you are being super specific for mobile development) is a cloud-based platform that provides developers with various sets of tools and services to create, manage and deploy applications without having to manage the underlying infrastructure. Basically, BaaS allow developers to build secure and scalable apps by aggregating and managing backend resources. Backend resources meaning database services, storage, analytics, serverless computing, etc. Cloud-based is just a cool way to say it is already deployed and on the internet. 
 
Why is this necessary? Are BaaS platforms for lazy developers and for developers who don’t know backend development? If you are a real coder, shouldn’t you build your own backends? Truth be told, most professional backend developers are using these BaaS services and platforms. Despite what Elon Musk currently thinks, application development can be extremely laborious, especially when dealing with compliance requirements regarding authentication and data protection. Having a third party service for something like authentication means that dedicated teams of professionals are handling it and to be blunt, if you get hacked you will not be legally responsible. 
 
I want to get into a high level overview of three BaaS platforms that have been on my radar for a little while now and that I think are really cool. 
 
The first one is Google’s Firebase. Released in 2012 and acquired by Google two years later, Firebase is the OG of next generation BaaS platforms. It was one of the first platforms to offer a service that allows all connected clients to be synced to a NoSQL database in real time, aptly called the Firebase Realtime Database. Having all data stored as JSON, synced in real time and being available offline made Firebase virtually universally awesome for iOS, Android, and web development. The Firebase Realtime Database does have drawbacks. It does not scale well. With complex data requirements the entire app can slow down and would also get expensive to run. Firebase now has a second option to handle more complex data called the Firestore. The Firestore is also NoSQL but stores data in documents organized into collections making it more suitable for large scale applications. These databases that put Firebase on the map are ironically where I see a lot of criticism in the community. Since these are Firebase specific databases, it might not be easy to migrate off of them to a different service. Since it is Google, if you are using Firebase you will be able to easily integrate any GCP (Google Cloud Platform) services. 
 
Next up is Supabase. Supabase call themselves an open source Firebase alternative. Supabase offers a lot of the same functionality as Firebase such as the realtime cloud-based database, authentication and serverless functions but deviates in some pretty significant ways. Aside from the obvious of being open source instead of being Google’s proprietary platform, Supabase is built on top of PostgreSQL. That means using relational databases instead of NoSQL. PostgreSQL is one of the most flexible and powerful databases around which means Supabase can handle much more complex data structures and queries out of the box. Supabase can also be self-hosted instead of being locked into the GCP ecosystem. Additionally they even have more robust security features than Firebase. The drawbacks of Supabase are mostly from how new the platform is. Supabase has only been around for a couple of years and is still actually in beta. I have read about breaking changes from API updates in the community, so developers need to stay on top of their projects. Supabase is definitely cutting edge. 
 
The final BaaS platform I want to talk about is AWS Amplify. Released in late 2017, Amplify was Amazon’s response to Firebase. Amplify leverages the gigantic AWS ecosystem and makes creating and managing these resources extremely accessible. AWS Amplify comes out of the box flushed with features using some familiar resources. It uses Cognito for authentication, DynamoDB as the database and can easily integrate any AWS service such as S3 or AWS Lambda. Amplify also leverages AppSync which does a lot of the heavy lifting in securely connecting to these resources through a GraphQL schema. AppSync can automatically generate a client-side library in multiple languages (JavaScript, iOS, and Android) that makes it easy to interact with the API from your application. In addition to the Amplify CLI, Amplify also has a visual builder to create and manage cloud resources. You can use either the CLI or visual builder or bounce between the two. Amplify also has hosting capabilities including support for Next.js 12 and up. Truth be told, AWS Amplify is so robust that this paragraph just scratches the surface of its capabilities. 
 
AWS Amplify is definitely the more powerful and more comprehensive BaaS platform on this short list but that also comes with being the most complex and the most expensive. For small and personal projects Firebase and Supabase are great options but they will have a hard time keeping up with AWS’s wide range of services and scalability options. 
 
When exploring technologies like these, I usually like to see who actually uses them. Since Supabase is so new, it was pretty hard to find any information on who is using it in production. For Firebase we have Lyft, Snapchat, Duolingo, Spotify, NPR and Alibaba. For AWS Amplify we have Airbnb, Netflix, Twitch, Zillow, Capital One and The New York Times. 
 
There are a ton of BaaS platforms to choose from, honorable mentions being Microsoft’s Azure and Hasura. They all provide database services, authentication services, and other features that make it easier to develop and deploy web and mobile applications. Additionally, most of them provide a range of other services, such as analytics, storage, and serverless computing. Choosing the right one will of course, ultimately come down to project requirements but also developer comfort zones. If you are already comfortable in AWS environments, using Amplify would make a lot of sense. If you are ethically opposed to Amazon as a company, Supabase might be worth exploring.

Exploring BaaS with AWS Amplify, Google Firebase and Supabase

large_19-baasheader.webp

medium_19-baasheader.webp

small_19-baasheader.webp

thumbnail_19-baasheader.webp

19-baasheader.webp

Backend as a Service

12.27.22
 
Very often, I see new developers asking whether or not they should be using class based or functional React components. The answer is always functional components and the reason is simple: hooks. 
 
Introduced in React version 16.8, which was released in February 2019, hooks offer a way to manage state and lifecycle methods in React components without having to write classes. Hooks quickly became best practice and industry standard for React. Hooks offer increased readability of React code and let you split components into smaller functions. The official recommendation for writing class based components is just to use them on legacy code bases that are already using them. The official React docs even admit that “classes confuse both people and machines”. 
 
React architecture emphasizes modular components and a React component is essentially a JavaScript function that will return HTML. Some React components just do that, return some HTML. Those components are known as pure functions or stateless components. A stateful component declares and manages local state in it. Keeping in step with the modular React architecture, isolating the logic to manage the state and side effects to be reusable is exactly what a hook is. 
 
React provides about a dozen standard built-in hooks out of the box. I don’t want to go too deep listing and explaining them all here because that could be its own blog post. The two most common built-in hooks are <code>useState</code> and <code>useEffect</code>, in fact you would probably be hard pressed to find a React code base that does not have <code>useState</code> or <code>useEffect</code> anywhere in the project. Conveniently, these two are all you really need to start building your own custom hooks. 
 
If you are totally new to React hooks, here’s a quick explanation of <code>useState</code> and <code>useEffect</code>. The <code>useState</code> hook allows you to set an initial state variable and then use it in the component or render that variable in the returned HTML. The <code>useState</code> hook uses the JavaScript array destructuring syntax which is easier to read and understand compared to the way you have to bind state in a class based component. 
 
The <code>useEffect</code> hook is used for manually changing the DOM from React components. Those operations are called side effects. The <code>useEffect</code> hook replaces the component class based lifecycle effects <code>componentDidMout</code>, <code>componentDidUpdate</code>, and <code>componentWillUnmount</code>. In plain English, you use <code>useEffect</code> when you need to set something after React updates the DOM, or when a page or component loads or refreshes. 
 
Why build a custom hook in the first place? There are a ton of great use cases and reasons to build your own custom hooks. Data fetching can often be redundant and whether you use the JavaScript fetch API or Axios, creating a <code>useFetch</code> custom hook can be helpful. When building an e-commerce store, the shopping cart is an excellent example for building custom hooks. A <code>useCart</code> hook can persist store items to local storage, remove the items, and then use the items for the checkout process. A custom hook for dark mode is a cool use case. Adding event listeners as custom hooks is also really cool and the specific use case that I will end with as an example. 
 
You may have noticed, the standard naming convention for React hooks is to name them with ‘use’ in the beginning of the title to easily identify them. Other than that they are just JavaScript functions that will use at least one built-in React hook. I want to show a really cool and simple custom hook I use in a lot of projects. As I mentioned in the last paragraph, this custom hook uses an event listener to detect when scrolling occurs on a page. I often use it to change the color or size of an element when you scroll on a page. It is a cool trick to have a navigation header transition as you scroll. 
 
```javascript
import { useState, useEffect } from 'react'

export default function useScrollPosition() {
const [scrollPosition, setScrollPosition] = useState(0)

useEffect(() => {
 const updatePosition = () => {
 setScrollPosition(window.pageYOffset)
 }

 window.addEventListener('scroll', updatePosition)

 updatePosition()

 return () => window.removeEventListener('scroll', updatePosition)
}, [])

return scrollPosition
}
```
 
First we set a default state value to the scroll position using the built-in <code>useState</code> hook. Then inside of the built-in <code>useEffect</code> hook, so when the the page finishes loading this hook will execute, we have a function that will set that state variable to the <code>window.pageYOffset</code>, which returns the number of pixels the document is currently scrolled along the vertical axis (up or down) on the page. Then the actual event listener is added with the new function. This hook tracks how many pixels have been scrolled, so I use it in a conditional statement; i.e. if useScrollPosition > 0 change color. 
 
Hooks really are super cool and can help you make your code both flexible and tailored exactly to your needs.

large_18-customreacthooks.webp

medium_18-customreacthooks.webp

small_18-customreacthooks.webp

thumbnail_18-customreacthooks.webp

18-customreacthooks.webp

Custom React Hooks

12.9.22
 
For this blog post I wanted to break down one of the most commonly asked algorithms in coding interviews. Companies like Amazon, Apple, Google, Microsoft, Adobe, Twitch, Spotify, Facebook, Uber and Tesla are reportedly still asking candidates to solve this algorithm. The famed LeetCode has thousands of these types of questions and Two Sum is the very first one they throw at you. 
 
There are basically four different ways to solve this problem. There is the brute force method, the two pointer method and then two different ways using hash tables (objects). I just want to just break down the first approach. The other approaches are technically better because of their time and space complexities but if you are new to coding or algorithms, solving this with any complexity is a huge win. Since most courses and resources are so focused on being the best, I wanted to write the blog post that I wish I found years ago when I first started getting into these. 
 
<a href="https://leetcode.com/problems/two-sum/" style="color:purple;">Two Sum</a>. Let’s get into it.
 
Given an array of integers (nums) and an integer (target), return indices of the two numbers such that they add up to the target. You may assume that each input would have exactly one solution, and you may not use the same element twice. 
 
Example 1: 
Input: nums = [2,7,11,15], target = 9 
Output: [0,1] 
Example 2: 
Input: nums = [3,2,4], target = 6 
Output: [1,2] 
Example 3: 
Input: nums = [3,3], target = 6 
Output: [0,1] 
 
In plain English, you get a list (array) of numbers and target number and have to find which two numbers in the list add up to the target. The only tricky part is that they ask you to return the indices and not the actual numbers but we will worry about that in a few minutes. 
 
I’ll show this in both JavaScript and Python but the approach is exactly the same in both languages. Off the bat, we see that we are expected to return a new list with our answers inside. The very first thing we code will be creating an empty list to put our answers inside and then return that list. We need to compare the numbers of the given list. To do so, we can use two for loops. Let’s open up the list with the first for loop. 
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1670613338/tsjs1_mkmpd6.png"/>
 
First JavaScript. Now Python.
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1670613338/tspy1_yis7bg.png"/>
 
Using the examples given with the directions, these will both print the same data to the terminal console.
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1670613338/term1_xclcmf.png"/>
 
We have our new empty list for our answers and we now have access to all of the numbers in the given array. Inside of our first for loops we are using i to access the indices of each number and conveniently we access the numbers using the same syntax for getting the number at i index. For loops. Wild. Still with me? Let’s open up that second for loop so we can compare the numbers. Best practice is to use j for the second index. J will run one index ahead of i.
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1670614429/tsjs2_wnwa8z.png"/>
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1670614429/tspy2_nj5lw0.png"/>
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1670614429/tsterm2_mryk8l.png"/>
 
Cool, now we have both for loops running and can now write some logic to compare the numbers. This is really the core of the entire problem. We want to see if one number (nums[i]) in the array plus another number (nums[j]) in the array equals the target number. We can accomplish this with an if else statement.
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1670615384/tsjs3_gycke8.png"/>
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1670615384/tsterm3_dvb7lt.png"/>
 
Now our algorithm is checking to see which numbers in the array sum to the target. Pretty cool. Even if you are really bad at math and have trouble figuring out if 2 + 7 = 9, don’t worry because the computer is now checking for us.
 
Now that our algorithm is finding out which numbers we need, we just need to fill that empty array from the beginning with our answers. Also remember from the beginning, the directions are asking for us to return the indices of the number and not the actual number. Instead of nums[i] and nums[j], we just need to put i and j into our answers array. With JavaScript, we can use the .push() method and with Python we can use .append(). We also do not need the else statement. 
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1670617319/tsjsfinal_ieuehv.png"/>
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1670617319/tspyfinal_jx3yrr.png"/>
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1670616492/tsfinalterm_v0ycl6.png"/>
 
Nice! We did it. Nothing too fancy, nested for loops and an if statement does the trick. I really hope breaking this down step by step and visualizing what each piece does helps somebody new on their coding journey.

One of the most popular interview algorithms in JavaScript and Python

large_17-twosumheader.webp

medium_17-twosumheader.webp

small_17-twosumheader.webp

thumbnail_17-twosumheader.webp

17-twosumheader.webp

Two Sum

10.27.22
 
There are so many ways to build an e-commerce store these days. You can of course build one from scratch. That involves building a traditional backend yourself. No matter what language and framework you use, you will be building a pretty robust API that is capable of managing inventory, orders, customers, admin functionality, payments, etc. If you are building the store for a client, the frontend will need an entire admin section where the client can run their business. The frontend can become pretty complicated also but I want to focus on the backend for now. 
 
Since e-commerce backends can be a ton of work for a single developer or even a small team, completely custom built backends are usually not ideal. Luckily there are many options to help. It would probably be pretty ignorant to write a blog post about e-commerce and not mention WooComerce. WooCommerce is the most popular e-commerce platform on the planet. There are a lot of reasons for that too. It is free, relatively simple to use, and it leverages all of the user friendly advantages that WordPress offers… except that is also one of the biggest reasons not to use it. WooCommerce is exclusive to the WordPress ecosystem. There are of course other all in one solutions like SquareSpace and Wix but as a developer these options can be pretty limiting. 
 
Headless e-commerce is usually a much more attractive option. As with most web development these days, decoupling the backend and frontend makes a lot of sense because it can increase performance which affects SEO and client retention as well as giving the developer complete control which means unlimited customization. There are a bunch of really cool companies providing headless e-commerce platforms too. The big players are Swell, BigCommerce, Saleor, Ordercloud, Vendure, Commerce.js, Spree, SalesForce Cloud Commerce and Shopify. That’s right, Shopify. Shopify offers API access and the ability to create apps that interact with a Shopify store allowing you to use Shopify as a headless option. 
 
Shopify is actually the second most popular e-commerce platform on the planet after WooCommerce. This chart is as of October 2022 and tracks the top one million e-commerce sites. 
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1666819170/ecommercechart_scccmf.png"/>
 
Shopify has an excellent reputation and is very attractive to developers and clients. Shopify provides a fully fleshed out and powerful admin panel for managing orders, products, customers, finances, marketing tools, discount codes and shop staff. Going headless does mean that not all of Shopify’s Apps will automatically work but using Shopify leverages their security and client and customer trust. 
 
For the frontend of headless e-commerce stores, I am usually a big fan of Next.js. I am a big Next.js fan regardless of e-commerce actually. Next.js is so powerful and versatile of a framework that it is possible to have data persist to a database through an ORM like Prisma and then have serverless API integrations for payments using Stripe or PayPal. That is pretty awesome for a frontend React framework but that of course means forgoing Shopify and becoming a totally different project. 
 
Building a headless Shopify storefront with Next.js from scratch is also no small task. You have to take state management into consideration. You need to be pretty proficient with GraphQL because Shopify’s API is GraphQL and not REST. You will need to build out the cart and customer checkout flow. This is where Hydrogen finally enters the conversation. 
 
Hydrogen is a React framework built by Shopify devs specifically for creating headless Shopify storefronts. Sign of the times huh? Hydrogen is borderline bleeding edge tech at less than two years old. The Shopify devs say they created Hydrogen for us, the developers. They had a goal to “provide a terrific experience for developers”. They achieved this by providing components that make it easier to connect back to Shopify’s backend. 
 
Hydrogen is built on Vite. It would’ve been super cool if they built it on Next.js, but I have read they are working on Next.js compatible components for the future. Vite is not a framework like Next.js. Vite is a JavaScript compiler similar to Webpack (which powers Next.js) that was built by Evan You. Evan You is famously known for creating Vue.js. Vite is French for “quick” and lives up to the name. Vite is known for having Server Side Rendering plugins that can give similar advantages that Next.js provides. The Shopify devs leveraged that to make sure that Hydrogen will have SSR capabilities to provide things like SEO. Hydrogen’s data fetching utilities are actually built with React server components. Vite is also highly configurable and should feel familiar even if you have never seen a Vite project. Vite provides the familiar index.html entry point and works out of the box with JavaScript, JSX, TypeScript and PostCSS. This means you can use JavaScript/TypeScript with Tailwind CSS. 
 
For DX experience, Hydrogen definitely has a fun vibe. The hydrogen config file essentially allows plug and play access to a Shopify backend. You provide a store domain and an API token and Hydrogen connects your app back to Shopify. That means Hydrogen provides all the complex GraphQL code for you. That’s not all they do for you out of the box. On top of tons of Shopify specific components that are useful for building the store, they also make the checkout flow super smooth. Once the customer is ready to check out, they are redirected back to Shopify with the cart items from the frontend. From there, the customer checkout process is safe, secure and out of the hands of the developer and the client. 
 
Since Hydrogen is cutting edge technology, not everything is super smooth though. Deployment was a small hurdle to get over. Off the bat, Hydrogen is sort of built to be deployed to Oxygen. Cool name play. Oxygen is Shopify’s recommended deployment platform for Hydrogen. The only catch is that your client needs to have a Shopify Plus account for you to be able to use Oxygen. The Hydrogen docs say you can deploy on Netlify (the original Jamstack platform), Vercel, Cloudflare Workers or even run it in a Docker container. My first attempt at Hydrogen deployment was with Netlify. Even though the documentation was pretty straight forward, I had some issues with Netlify’s edge functions. Netlify says their edge functions are still in beta. Instead of fighting with Netlify’s beta edge functions, I went to Vercel with my code and successfully deployed Hydrogen. 
 
I think Hydrogen is super cool and an awesome tool for developers who’s clients want to use Shopify for their business. I am really excited to follow the project and see how it continues to grow.

large_16-hydrogenblogpic.webp

medium_16-hydrogenblogpic.webp

small_16-hydrogenblogpic.webp

thumbnail_16-hydrogenblogpic.webp

16-hydrogenblogpic.webp

Hydrogen

10.15.22 
 
I have been wanting to write a blog post about data structures and algorithms and since it’s October and officially horror movie season, I figured I would start by picking the scariest topic I could think of. A topic feared by comp-sci students, aspiring coders and sometimes even seasoned devs. Recursion. 
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1665777146/recursionmeme1_xgxm4n.jpg"/>
 
I think one of the big reasons that recursion is so feared is because it is very avoidable. Anything that uses recursion can be accomplished with iteration of for loops. A close second is definitely because it actually can be pretty confusing. Third might be because it can break code easily. If you don’t have a base case, you can send your code into an infinite loop. Fourth would probably be that using recursion doesn’t even necessarily mean improving the space and time complexity of your algorithm, meaning it probably won’t even increase performance. 
 
Then why use it at all? Recursion can be an elegant way to increase readability. Yes, there are some specific cases where it can improve the time complexity of an algorithm (google Tower of Hanoi if you are interested in a famous one). It sometimes helps with object traversal. It also helps developers write less code by reducing the actual amount of lines they need to write but it most importantly makes certain things easier to demonstrate, explain and read. Which is huge when dealing with super complicated algorithms. This is also why new developers should get a firm grasp on recursion. As a new developer, you will be reading a lot of other people’s code. And let’s be honest, recursion is a favorite topic for interviewers. 
 
Face the fear. What is recursion? To put it simply, recursion is when a function calls itself. Technically not exclusive to computer science, recursion occurs when a thing is defined in terms of itself. I am obviously talking about it in terms of computer science and for this blog post I will stick to JavaScript for examples and context, even though recursion is possible in (probably) all programming languages. 
 
Functions use other functions all the time. When a function is passed to another function as an argument that is called a callback function. 
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1665778954/a88_vvgj2y.jpg"/>
 
Mandatory Inception meme. Except a recursive function isn’t just a function within another function. Again, it is when a function calls itself. Let’s just get into an example. A famous use case for recursion is finding the factorial of a number. In case you need a little refresher on 10th grade math, the factorial of a number is the product of all positive integers less than or equal to the given integer. It is also written with an exclamation mark. So, 5! = 1 x 2 x 3 x 4 x 5 = 120.
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1665780273/factorials_oqpmvp.png"/>
 
That first function above is the recursive function that calls itself. The second is a bonus of doing it with a for loop. Even though these are relatively simple, I think they demonstrate how recursion can actually make code a little easier to read despite the double take of it calling itself. 
 
As I mentioned earlier, a recursive function requires a base case or it will send your code into an infinite loop. It will actually cause a stack overflow. A stack overflow is actually more than just a website where people steal code from. A stack is a linear data structure. In a stack, functions rely on each other to move on. They are either first in, last out or last in, first out. When a function is called it is placed (pushed) on top of the call stack and when JavaScript sees the return keyword or when the function ends, the compiler will remove (pop) it from the stack. An overflow occurs when a function calls itself so many times that the space needed to store the variables and information associated with each call is more than can fit on the stack and whatever is running your code (probably a browser if you are coding in JavaScript) stops or crashes. A base case is usually a conditional statement to end the loop. 
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1665781775/sumrange_zpxwbu.png"/>
 
The last thing I want to share here is a weird little story that kind of stuck with me and can help you understand recursion for problem solving. The setup is weird, don’t overthink it. A little boy is hanging out with a stubborn dragon. The little boy has a list of numbers and needs to know which numbers are odd and which are even and asks the dragon for help. The stubborn dragon says he will only tell him if the first number in his list is odd or even. So the little boy asks the dragon about the first number in his list and gets his answer. Then instead of quitting, he removes that first number from the list and asks the dragon again and gets his answer for the second number and repeats that process until he has all of his answers. This clever hypothetical boy was using a recursive algorithm.

Defining functions in terms of themselves

small_15-recursion.webp

thumbnail_15-recursion.webp

15-recursion.webp

Recursion

8.30.22
 
Algorithms. Validation. Sanitization. Web Scraping. Data wrangling. Search Engines. Natural language processing. Syntax highlighting. A common denominator that threads across all of these concepts are the use of Regular Expressions. 
 
I have been mentoring a friend who just graduated from a bootcamp and I brushed up on Regular Expressions so we can grind some Leet Code. I thought this could be a cool topic for a blog post. 
 
When I first started learning to code, Regular Expressions really confused me. A lot of code, especially Python, can be very readable to an untrained eye. Even if you don’t know what a specific built-in function does, you can usually figure it out by breaking it down, context helps a lot, but with Regular Expressions, you come across forward and back slashes, brackets, upper and lower case single letters, carrots, dashes, question marks, dollar signs, pipes, etc. all jumbled together. To me, it looked like code that only computers can understand. Like binary code but maybe worse. 
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1661887779/bender-binary-gif_inmn2j.gif"/>
 
The truth is, Regular Expressions can be very readable if you understand how it works. They can look intense because they can be complex but at the core there are some pretty simple rules. 
 
So, what is it? A Regular Expression is a way to search through a string (or text) or more specifically, a sequence of characters that specifies a search pattern in text. The concept of Regular Expressions, or just Regex (sometimes regexp) dates back to the 1950’s and the common syntax dates back to the 1980’s. Even though the concept of regex is programming-language agnostic, programming languages do use Regex a little differently. I will show some regex using JavaScript and Python.
 
The basic syntax for regex is to put a pattern inside of two forward slashes followed by an optional flag (modifier): /pattern/flag 
 
Some common flags (or modifiers) are: 
i • perform case-Insensitive matching 
g • perform a Global match 
m • perform a Multiline matching 
 
Some more you can use: 
s • allows to match newline characters or Single line, aka .dotAll. 
u • Unicode: treat a pattern as a sequence of unicode code points. 
d • generate indices for substring matches. 
y • perform a sticky search that matches staring at the current position in the target string 
 
Ok, now onto the patterns. Square brackets [ ] are how you find specific characters or digits. You can search for specific characters or digits with brackets by simply putting what you are looking for inside the brackets: [abc] or [123]. You can also use brackets to find ranges: [a-m] or [0-9]. Add a carrot to define what you are NOT looking for: [^abc] or [^0-9]. Similar to brackets, you can use parenthesis ( ) to find exactly what you are looking for, and you can look for multiple things by separating them with a pipe character |: (x|y). Not too bad so far right? 
 
After flags and patterns, we have metacharacters. These give your search some more power. These are the backslashes that I mentioned earlier. 
\w • find a word character 
\W • find a non-word character 
\d • find a digit 
\D • find a non-digit character 
\s • find a whitespace character 
\S • find a non-whitespace character 
\b • find a match at the Beginning \bWORD or end WORD\b of a word 
\B • find a match, but not at the beginning/end of a word 
\n • find a new line character 
\t • find a tab character 
\uxxxx • find the unicode character specified by the hexadecimal number xxxx 
 
Finally, we have quantifiers, which as the name suggests, defines quantities.
n+ • Matches any string that contains at least one n 
n* • Matches any string that contains zero or more occurrences of n 
n? • Matches any string that contains zero or one occurrences of n 
n$ • Matches any string with n at the end of it 
^n • Matches any string with n at the beginning of it 
?=n • Matches any string that is followed by a specific string n 
 
Ok cool, now that those definitions are out of the way, we can see it in action. 
 
In Python, you have access to a built-in regex package. After you import it, you have access to several functions that work with regular expressions. One of those functions is re.sub(), which can replace the matches with the text of your choice. For this example and the following JavaScript version, know that the text variable is the string Method Man. 
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1661887762/python-regex_xsbcvl.png"/>
 
In the above Python example, we are importing the regex built-in package and then assigning a variable to the re.sub() function and passing in the search term and what we want to replace the search term with. For the search, I am simply using parenthesis just to find exactly what I am looking for. Then we use an f string to print out a new string using the new variable. 
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1661887762/js-regex_urkyrh.png"/>
 
The above is the JavaScript version of the Python example. In JavaScript, you don’t need to import anything and the built-in function replace() works the same as Python’s re.sub(). In the JavaScript version, we are again defining a new variable and inside the replace() function, we are using regex to find the string and we are using the i flag to modify the search to be case insensitive. The JavaScript equivalent to f strings are template literals (back ticks) so we can pass in our variables into a string. 
 
There is a cool website where you can practice regex or see it in action before you implement a pattern into your code. Below is from <a href="https://regexr.com/" style="color:purple;"> regexr.com</a>. 
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1661887762/regexer-example_bx2ltf.png"/>
 
So, in that example we have our regex pattern inside our forward slashes with the g global flag on it, which will make it search through the entire string. The pattern is searching for all non-word characters including underscores which are highlighted. 
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1661887762/js-stripped-regex_qsgjjg.png"/>
 
In JavaScript, we can use that regex pattern using the replace() method to manipulate the string. After we use the regex pattern, we can replace everything we found with an empty string (nothing) to return just the bare characters. This is a technique known as sterilizing a string. 
 
These are some pretty simple examples. Again, these regex patterns can become very complex very quickly but as you can probably tell, they can also be pretty powerful. If this is the first time you are reading about regex go check out how your programming language of choice handles these patterns. Regex is definitely an essential tool to have in your belt and something that does not have to be intimidating.

Regular Expression in Python and JavaScript

large_14-regex.webp

medium_14-regex.webp

small_14-regex.webp

thumbnail_14-regex.webp

14-regex.webp

Regex

7.22.22
 
This blog post has felt inevitable for a while now. If you are even loosely tapped into the developer community, there is no doubt that you have heard about TypeScript. I have been hearing the murmurs for a few years now, seemingly ever since I started learning about React. Over the last few years, it feels like those murmurs have turned into a roar. 
 
When I first decided to make the jump to take programming seriously, JavaScript seemed to have a lot of haters despite its growing popularity. After all, it is a weakly typed programming language. Without really knowing what that meant, I took the advice of my friend (turned mentor) and opted to make Python my primary tool to learn modern computer programming. After all, Python is not only a strongly typed language but a dynamically typed language as well. Sounds way better doesn’t it? The thing is, Python is a strong type language because of the interpreter, not the coder. The interpreter keeps track of all variable types. A Python program will use built in functions behind the scenes to test variable types and correct usage. The official python.org website even says ‘Python tries to stay out of your way while giving you all you need to implement strong type checking.’ That is also what makes Python a dynamically typed language. Python has relatively simple syntax compared to the the other strong type languages like C# and Java, which is definitely a reason to recommend it to new coders. Python syntax is simpler because C# and Java are statically typed languages. More on that in a bit. There are actually a few more reasons I still recommend Python to new/aspiring coders. Python sort of forces you to learn some DevOps along the way. If you are a Python dev, you will be working with virtual environments, probably some container management tools like Docker and Kubernetes. Python is also a backend language so it involves relational databases. Python is also extremely versatile and used not just as a backend for web tech but is also the leading language for data science technologies and even natural language processing. 
 
We get it, Python rules but who can resist the allure of JavaScript and React. In fact, in my humble opinion, ignoring JavaScript and React today would be a huge misstep. Sometimes it feels like the entire internet was rebuilt using React. Plus with Node.js you can develop powerful backends to manage databases, build APIs, etc, making JavaScript a full-stack language. But this means using a weak type language. What makes JavaScript a weak typed language is that you do not have to specify variable type in advance. JavaScript code is compiled, usually in a browser, and can intermingle data types. This is what makes JavaScript code both flexible for many different kinds of applications but also vulnerable to errors and bugs because you often won’t notice the errors or bugs until the code is ran. 
 
This is where TypeScript enters the conversation. TypeScript is not another coding language, it is a superset of JavaScript. What does that mean? Check out this image.
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1658508430/1_u1YMvsOc4EipjnESaqCTAw_et1plg.png" width="200"/>
 
You can think of TypeScript as JavaScript +. All modern JavaScript actually works in a TypeScript file. That is pretty cool. Created by Microsoft and open-sourced in 2012, TypeScript was created to reduce unexpected behavior in JavaScript by statically and strongly defining types to clarify the structure of data. TypeScript makes JavaScript into a strong type language. Take that, JS haters.
 
I feel like this very simple TypeScript function demonstrates exactly what I am talking about.
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1658508412/Screen_Shot_2022-07-22_at_12.09.37_PM_dew7ls.png"/>
 
We have a simple JavaScript function that takes in an argument, which is a name and then will simply say Hello to the name given to the function. Except we have a static type defining the name to be a string. Names are usually strings so that makes sense. But since the argument is typed to be a string, it can never be anything else. If you pass in a number, you get an error immediately. This is lovingly referred to as making TypeScript angry. TypeScript gets angry a lot and will throw red squiggly lines all over your code. This is how you catch those bugs and errors while you code instead of after you try to run the code. 
 
The red squiggles aren’t the only way TypeScript will check your code for bugs and errors. TypeScript also involves a command line compiler. You run a simple command (tsc) on a TypeScript file in your terminal and it will either create a JavaScript version of your code or tell you what problems your TypeScript code has. 
 
TypeScript actually has a ton of ways of catching these errors. Another way is through return types. TypeScript can infer return types, or you can have explicit return types and if you don’t want to return a type you can still annotate that by voiding the return type. Using the void keyword really makes TypeScript feel a lot closer to Java and the C languages.
 
Along with the primitive data types (number, string, boolean, null and undefined), TypeScript allows for custom types. Custom typing is probably where TypeScript can really become a super powerful tool. That allows developers the freedom to type anything. Union types are cool too. Union types allow you to specify data to be more than one type of data. That is a concept known as type narrowing. You can use conditional statements, known as type guards to make sure the wrong data type is not passed in or returned. 
 
The last TypeScript concept I want to touch on is interfaces. A TypeScript interface is only used for typing objects. The same objects in Object Oriented Programming (OOP). An interface describes the shape of an object. They are used to provide information about object property names and the data types their values hold. An interface adds the functionality of strong type checking for functions, variables, or the class that is implementing the interface.
 
Ok cool, without getting too deep down the rabbit hole, I think that is an awesome intro to TypeScript. Now I have to go make all my React apps type safe...

large_13-typescript.webp

medium_13-typescript.webp

small_13-typescript.webp

thumbnail_13-typescript.webp

13-typescript.webp

TypeScript

6.26.22
 
In light of the previous post, I rebuilt this site from scratch using all of the technologies I mentioned. Next.js, Tailwind CSS and Strapi. I am actually typing this from the Strapi CMS. I want to talk about Server Side Rendering (SSR) and Static Site Generation (SSG) in this post because developing with SSR and SSG in React is different than developing a traditional React front-end. SSR and SSG are also part of what make Next.js so awesome. 
 
First a little about this site. I split the project into two repositories, the <a href="https://github.com/Adamhunter108/adam-nextjs-site" style="color:purple;"> main Next.js project</a> and the <a href="https://github.com/Adamhunter108/blog-backend-strapi" style="color:purple;"> Strapi backend</a>. The tech stacks ended up being pretty cool too. First of all they are both Node.js applications. The Strapi backend is deployed continuously to Heroku through the GitHub repo, it is using a PostgreSQL database for these blog posts, and Cloudinary for all of the images. The Next.js repo deploys continuously to Vercel, I am obviously using React because Next.js is a React framework, I already mentioned Tailwind CSS (my favorite new tech), and I ended up using some of the back-end magic of Next.js to create some serverless functions to integrate SendGrid for sending emails (how the contact form works) and connecting to the MailChimp API for the newsletter sign up form. 
 
As I have mentioned in previous posts, a traditional React front-end involves manipulating the virtual DOM which makes it client side (in the browser). In web development, having all your code be client side is usually not ideal. SEO is a huge reason it is not ideal. If all of your important content involves manipulating virtual elements of a web page, search engine crawlers won’t be able to read your content. To put it simply, nobody will be able to google you or find your content. Which is a big deal to a lot of businesses. So, Next.js comes in and solves this by making it easy to export React components as actual HTML pages rendered server side. Which means your React code is crawlable. That really rules. The possibilities are endless. Loading content server side is also mainly where coding a traditional React app will differ the most. The content that you want to be delivered server side needs to be there and exist at the time the page loads or the build will fail. And if you are dynamically delivering content via an API to hydrate your page, like this very post, you cannot use typical React methods and hooks like useState and useEffect. 
 
Instead of using the useState and useEffect React hooks, Next.js offers a couple built in APIs to fetch data. The first is a function called getServerSideProps. The way getServerSideProps works is, if you export it on one of the server side rendered pages, it will pre-render the data on each request. This is important because this is where you make your API calls for data that needs to be rendered server side. You then simply pass that data to the main page component as props and then your component has full access to the data. getServerSideProps. The name makes sense. That completely solves the issue of handling dynamic API data server side, however there are some performance sacrifices that are made when using this method. You are sacrificing performance of your application because as your user uses your application they will have to be hitting the server for every request. 
 
This is where Static Site Generation (SSG) can help. Static Site Generation is a technique where you can pre-render an entire page at build time. For my meta reference, when you visited the landing page of this website, this blog post was also built. So, when you navigated to this page, the content did not have to load because it was already there. Pretty cool. This is done using the other built in Next.js data fetching API function, getStaticProps. Code wise, it is nearly identical to getServerSideProps, except when getStaticProps is used you are implementing SSG and the page that you are using it on will be pre-rendered at build time. 
 
It is also worth noting that if you are using SSG and getStaticProps, and dynamic routing (like this page), you need to define a list of paths to be statically generated. Next.js provides another API function to use in addition to getStaticProps, which is getStaticPaths. 
 
Again, feel free to check out the source code for this site to see exactly how all of this is done. In the code, I first start with the useState and useEffect hooks, comment them out and then go server side, comment that out and then go SSG and you can see how all the methods work.

small_12-ssr.webp

thumbnail_12-ssr.webp

12-ssr.webp

Server Side Rendering & Static Site Generation

4.17.22
 
Those last three posts ended up being really code heavy. Those posts ended up essentially being an in-depth walkthrough on how start a fullstack web-app using Django/Python and React. I want to shift gears and go back to a higher level overview of a different stack I have been focusing on and am pretty excited about.
 
If you are into web development professionally or as a hobby it is likely that you have at least come across the term ‘jamstack’. Let’s define the acronym: J stands for JavaScript, the A stands for APIs and the M is Markup. Markup as in the same M that is in HTML; meaning human readable code for defining elements on a document. Jamstack web development comes with an entire ethos. Jamstack.org calls it a movement. The core principles of jamstack development are decoupling the frontend and backend and connecting them via an API, pre-rendered static first frontends, and enhancing them with JavaScript. If you follow these principles your app/website will have excellent performance, security, scalability and most importantly will be so cost effective that your app/site could potentially be free to run.
 
JavaScript and APIs… are you a jamstack dev without even fully realizing it? Probably, or at least close. It’s pretty hard to avoid that first letter in the acronym. JavaScript is modern web development so let’s start there. About a year ago I actually wrote a blog post on Next.js. I was just exploring it at that point and still getting comfortable with React and Node.js. Now, Next.js is my preferred React framework for web development. Next.js has become insanely popular and with good reason. It is a hybrid framework capable of static generation and server side rendering. A traditional React app is loaded and rendered on the client (browser) but Next.js allows for pages to be rendered by the server. Why does that matter? SEO. With traditional React apps and DOM manipulation it is difficult for web crawlers to read what is going on. Next.js comes out of the box with some of familiar web elements in its index.js entry point like head, main and footer. You don’t have to be a web expert to know that the head of a webpage is important for defining meta data which is SEO 101. This is probably why Next.js calls itself the production ready React framework. Next.js also has a ton of features that make it awesome like built in support for environment variables, testing with Jest and Cypress, TypeScript support, and automatic dynamic route building for pages and APIs.
 
If you are using Next.js and adhering to the jamstack ethos, you will probably need a headless CMS for your project. Check out this graph comparing satisfaction to usage among polled jamstack devs from last year.
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1654548223/Screen-Shot-2022-04-17-at-7.19.55-PM-1024x706_kcs2wr.png"/>
 
WordPress having the number one spot for most used CMS is no shock but there are some other really cool options in the top 10. If we are going by satisfaction score, the top 2 are Sanity and Strapi. Tuning into the jamstack world, this wasn’t really a surprise either as both seem to be super popular right now. I dug into both to see what would be better for a project I have coming up.
 
Off the bat, I can see why Sanity has so much hype behind it. They make it super easy to launch a live project. You authorize your GitHub and Netlify accounts and you can have Sanity automatically bootstrap a project, create a git repository and then launch it live on Netlify with no more than a few clicks. Once that is set up, you clone into the repo and every time you push changes to the main branch the changes are live. The CMS is also obviously automatically set up and pushes updates to their template. It was pretty cool that they allow you to do launch a live backend for free. I will say, I tried a few of their templates and with almost certainty that there was no user error, some of the builds did fail. I am very comfortable with both GitHub and Netlify besides all the configuration was supposed to be automatic. Not a big deal, but it was a little bit of a turn off.
 
On to Strapi. Like Next.js, I actually touch on Strapi in a blog post from about 10 months ago when I was exploring headless CMS. I probably did one of their quickstart tutorials and moved on but this time I was looking at it with fresh eyes. Unlike Sanity, Strapi is more of a true Node.js backend. It almost reminded me of an Express.js backend. To create content types you actually must develop with Strapi locally. Strapi will not even allow admins to create content types on a live server. I definitely learned that the hard way… but now I’ll never forget. It comes out of the box with an SQLite database, which is very familiar to Django devs and just like Django you can configure it to use other databases such as PostgreSQL which is really cool. It also comes with an API server that is served on port 1337 by default. If you are an old school internet nerd, you know the developers of Strapi are too. For those who don’t know, <a href="https://www.urbandictionary.com/define.php?term=1337" style="color:purple;">1337</a> is code for an elite hacker language. Another cool thing is that similar to Next.js, it will automatically create your API routes for you based on your content types. What that means is that whatever you create will be available via http://localhost:1337/api/<your content type> . Then you just call in your data from the frontend with your preferred fetch method, mine is axios, and the authentication bearer token that you generate from Strapi like this:
 
```javascript
 const { data } = axios.get(API_URL, {
 headers: {
 'Authorization': `bearer ${API_TOKEN}`
 }
 })
 .then(function(response) {
 // get your data
 })
 .catch(function (error) {
 console.log("There's an API error")
 })
```
 
Let’s see what this actually looks like. On your local Node.js server at http://localhost:1337/admin/ you can create content types for your needs. I made one for a news section that would have title, a body and an image:
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1654548318/Screen-Shot-2022-04-15-at-1.35.15-PM-1024x776_v3s0gu.png"/>
 
When creating any API, I like to test it using Postman before building the frontend:
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1654548448/Screen-Shot-2022-04-15-at-4.24.36-PM-1024x795_yv0ymn.png"/>
 
So that is what the Strapi API actually looks like. If all is well at this point, you can render your data out to your frontend:
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1654548495/Screen-Shot-2022-04-18-at-3.16.30-PM-1024x837_daeira.png"/>
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1654548508/Screen-Shot-2022-04-15-at-4.23.06-PM-1024x776_hzkiwu.png"/>
 
Now the content that I entered through the CMS admin panel is being dynamically rendered to the Next.js frontend via the API and is being stored in the SQLite database. This is technically now a fullstack app that a client would be able to update and make posts without touching the code. And best of all, a simple application like this can be hosted for free.
 
If you noticed the third logo on my little blog header graphic, you can probably guess that I want to talk about Tailwind CSS now. I won’t go too deep about Tailwind here, l could/should probably do an entire post about it. Tailwind is a CSS utility-first framework and it is awesome. With a little background in CSS concepts, you can make your elements look super modern using prebuilt but customizable inline CSS classes right into your JSX (or regular HTML). It is not entirely different than using a styled component library like Bootstrap but since they both use inline classes it is probably best to choose one or the other. Tailwind wins over styled component libraries for a few reasons. Not only is it much more immediately customizable but when compared to a library like Bootstrap specifically, Tailwind builds down to a much smaller size which will ultimately increase performance. The documentation is great, has a huge community around it, it feels intuitive, and honestly I think it looks cool. They even have some prebuilt component libraries but they are not free.
 
So that is a little about jamstack web dev. Obviously, you can use any of these tools alone or combined with other tech. If I ultimately decide to use Strapi or not I will for sure be using Next.js styled up with Tailwind a lot more from now on.

Lightweight and modern trend in web development

large_11-jamstack.webp

medium_11-jamstack.webp

small_11-jamstack.webp

thumbnail_11-jamstack.webp

11-jamstack.webp

Jamstack Web Dev

Using Redux we connect this React app to the Django backend.

large_10-build_react_app_pt_ii.webp

medium_10-build_react_app_pt_ii.webp

small_10-build_react_app_pt_ii.webp

thumbnail_10-build_react_app_pt_ii.webp

10-build_react_app_pt_ii.webp

Let's build a React app with user account functionality. Part II

2.25.22
 
With the API that we built in the previous post, let’s keep going and build a frontend with React.
 
To make sure all syntax and dependencies are up to date, I will start this from scratch. In part 1, I will show you exactly how to create a React app and get everything set up and looking nice. I will use Bootstrap for styling and React Router for the SPA (single page application) feel. In part 2, I will implement Redux and finish the functionality.
 
You don’t need to use a React toolchain to write React code, but using them is standard practice for a reason. Create React App is an awesome tool to get a React boilerplate set up for a frontend build using a Django (or any) backend. Since this is JavaScript, Create React App is a Node.js application and will require Node.js (version 14 or higher) to be installed. Node.js comes with nvm (node version manager) to change to a specific version of node and to update it.
 
```bash
$ # check node version
$ node -v
$ # install latest version of node
$ nvm install node
$ # create react app
$ npx create-react-app <app-name>
$ # make sure it worked
$ # change into newly created app directory
$ cd <app-name>
$ # start development server
$ npm start
```
 
If that was successful, the React app will be available to view in a browser at ***http://localhost:3000*** or on any device on the network at port 3000.
 
Now is when I usually like to do some small customizations, like change out the favicon, change the page title in project-name/public/index.html, set up tests, get rid of the boilerplate CSS and the stock code in ***project-name/src/App.js***.
 
Next I like to make the components and screens directories. The screens are technically React components also, but it is good practice to stay as organized as possible. When you have a lot of components and screens, this makes finding your files easier.
 
```bash

$ # control + D (Mac/Linux) will stop the dev server
$ # change into the src directory
$ cd src
$ # create directories for components and screens
$ mkdir components screens
$ # change into new components directory
$ cd components
# create a JavaScript file for the header component
$ touch Header.js 
$ # change into new screens directory
$ cd ../screens 
# create JavaScript files for the Home, Login and Register screens
$ touch HomeScreen.js LoginScreen.js RegisterScreen.js
$ # change back to src directory
$ cd ..
$ # open the src folder
$ open .
```
 
I’m going to use React Bootstrap components and a Bootswatch theme. Download the bootstrap.min.css file from theme of your choice and add it to the src folder that we just opened. Import the new CSS file in index.js:
 
```javascript
import './bootstrap.min.css'
```
 
Hit save and that should theme the app.
 
I like to make basic exported React functional components in the new screens and components so they aren’t blank files. Something as simple as this:
 
```javascript
import React from 'react'
function RegisterScreen() {
 return (
 <div>RegisterScreen</div>
 )
}
export default RegisterScreen
```
 
Now we can install React Bootstrap.
 
```bash
$ # change to project root directory
$ cd ..
$ # install react bootstrap
$ npm install react-bootstrap
$ # start dev server again
$ npm start
```
 
Configure App.js with the HomeScreen and Header components, move it into a React Bootstrap Container. We are going to import it, add a JSX main tag to define the body, add some Bootstrap padding to it, and then wrap the body in the Container:
 
```javascript
import { Container } from 'react-bootstrap'
import Header from './components/Header'
function App() {
 return (
 <div>
 <Header />
 <main className="py-3">>
 <Container>
 <HomeScreen />
 </Container>
 </main>
 </div>
 );
}
export default App;
```
 
Since we already added the exported functional components to the Header and HomeScreen, we won’t get an error with the dev server running and now we will see the changes immediately as we build them.
 
One thing that makes React apps so lightning fast is not reloading the app to navigate to another page. This is accomplished by changing regular href links to React Router links. Since we are using React Bootstrap, we want to use react-router-bootstrap so our links will still be styled by the CSS. So we need to install both:
 
```bash
$ # control + D will stop the dev server
$ # install react-router-dom
$ npm install react-router-dom
$ # install react-router-bootstrap
$ npm install react-router-bootstrap
$ # turn server back on
$ npm start
```
 
React Router v6 is the latest version and to set it up you need to add Routes and Route paths to App.js. Let’s import the other two screens and set the url routing:
 
```javascript
import { Routes, Route, Link } from "react-router-dom";
import { Container } from 'react-bootstrap'
import Header from './components/Header'
import HomeScreen from './screens/HomeScreen'
import LoginScreen from './screens/LoginScreen'
import RegisterScreen from './screens/RegisterScreen'
function App() {
 return (
 <div>
 
 <Header />
 <main className="py-3">
 <Container>
 <Routes>
 <Route path="/" element={<HomeScreen />} />
 <Route path="login" element={<LoginScreen />} />
 <Route path="register" element={<RegisterScreen />} />
 </Routes>
 {/* <HomeScreen /> */}
 </Container>
 </main>
 
 </div>
 );
}
export default App;
```
 
To finish setting up React Router make a quick import and edit to index.js:
 
```javascript
import React from 'react';
import ReactDOM from 'react-dom';
import { BrowserRouter } from "react-router-dom";
import './index.css';
import './bootstrap.min.css'
import App from './App';
import reportWebVitals from './reportWebVitals';
ReactDOM.render(
 <BrowserRouter>
 <App />
 </BrowserRouter>,
 document.getElementById('root')
);
// If you want to start measuring performance in your app, pass a function
// to log results (for example: reportWebVitals(console.log))
// or send to an analytics endpoint. Learn more: https://bit.ly/CRA-vitals
reportWebVitals();
```
 
I think Font Awesome Icons are cool. They look good, have a ton of free ones, and are easy to use. To be able to use Font Awesome Icons:
 
Get the font-awesome CDN link and add it to project-name/public/index.html and then just add the i tag where you want the icon. In index.html:
 
```javascript
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.0.0/css/all.min.css" integrity="sha512-9usAa10IRO0HhonpyAIVpjrylPvoDwiPUiKdWk5t3PyolY1cOd4DSE0Ga+ri4AuTroPR5aQvXU9xC6qOPnzFeg==" crossorigin="anonymous" referrerpolicy="no-referrer" />
```
 
Ok, let’s finally get into Header.js.
 
Change the div to a header tag. Grab some Bootstrap Navbar code to customize. I am using the off-canvas menu. Change href links to Link Containers to get that SPA (single page application) feel.
 
```javascript
import React, { useState } from 'react'
import { Navbar, Nav, Container, NavDropdown, Form, FormControl, Button } from 'react-bootstrap'
import { LinkContainer } from 'react-router-bootstrap'
import Offcanvas from 'react-bootstrap/Offcanvas'
function Header() {
 return (
 <header>
 <Navbar bg="black" variant="dark" expand={false}>
 <Container fluid>
 <LinkContainer to='/'>
 <Navbar.Brand> 
 <img
 alt=""
 src="https://emojipedia-us.s3.dualstack.us-west-1.amazonaws.com/thumbs/240/apple/285/fire_1f525.png"
 width="30"
 height="30"
 className="d-inline-block align-top"
 />{' '}
 App Name
 </Navbar.Brand>
 </LinkContainer>
 <Navbar.Toggle aria-controls="offcanvasNavbar" />
 <Navbar.Offcanvas 
 id="offcanvasNavbar"
 aria-labelledby="offcanvasNavbarLabel"
 placement="end"
 >
 <Offcanvas.Header closeButton>
 <Offcanvas.Title id="offcanvasNavbarLabel">Offcanvas Menu Title</Offcanvas.Title>
 </Offcanvas.Header>
 <Offcanvas.Body>
 <Nav className="justify-content-end flex-grow-1 pe-3">
 <LinkContainer to='/'>
 <Nav.Link> Home</Nav.Link>
 </LinkContainer>
 <LinkContainer to='login'>
 <Nav.Link> Log in</Nav.Link>
 </LinkContainer>
 </Nav>
 <Form className="d-flex">
 <FormControl
 type="search"
 placeholder="Search"
 className="me-2"
 aria-label="Search"
 />
 <Button variant="outline-success">Search</Button>
 </Form>
 </Offcanvas.Body>
 </Navbar.Offcanvas>
 </Container>
 </Navbar>
 </header>
 )
}
export default Header
```
 
Before we build out the LoginScreen and RegisterScreen, create FormContainer.js in src/components.
 
```javascript
import React from 'react'
import { Container, Row, Col } from 'react-bootstrap'
function FormContainer({ children }) {
 return (
 <Container>
 <Row className="justify-content-md-center">
 <Col xs={12} md={6}>
 {children}
 </Col>
 </Row>
 </Container>
 )
}
export default FormContainer
```
 
Now we can use the FormContainer we just built along with React Bootstrap Form, Button, Row, Col, and Card components for the LoginScreen and RegisterScreen.
 
LoginScreen.js
 
```javascript
import React, { useState, useEffect } from 'react'
import { Link } from 'react-router-dom'
import { Form, Button, Row, Col, Card } from 'react-bootstrap'
import FormContainer from '../components/FormContainer'
function LoginScreen({ location, history }) {
 return (
 <Card 
 className="text-center"
 >
 <FormContainer>
 <Card.Header as="h3"> Sign In</Card.Header>
 
 <Form>
 <Form.Group controlId='email'>
 <Form.Label> Email Address</Form.Label>
 <Form.Control
 type='email'
 placeholder='Enter Email'
 >
 </Form.Control>
 </Form.Group>
 
 <Form.Group controlId='password'>
 <Form.Label> Password</Form.Label>
 <Form.Control
 type='password'
 placeholder='Enter Password'
 >
 </Form.Control>
 </Form.Group>
 
 <Button type='submit' variant='dark'>Sign in</Button>
 </Form>
 <Row className='py-3'>
 <Col>
 Don't have an account yet? <Link to={'/register'}>Make one here.</Link>
 </Col>
 </Row>
 </FormContainer>
 </Card>
 )
}
export default LoginScreen
```
 
RegisterScreen.js
 
```javascript
import React, { useState, useEffect } from 'react'
import { Link } from 'react-router-dom'
import { Form, Button, Row, Col, Card } from 'react-bootstrap'
import FormContainer from '../components/FormContainer'

function RegisterScreen() {
 return (
 <Card 
 className="text-center"
 >
 <FormContainer>
 <Card.Header as="h3"> Create An Account</Card.Header>
 
 <Form>
 
 <Form.Group controlId='name'>
 <Form.Label> Name</Form.Label>
 <Form.Control
 required
 type='name'
 placeholder='Enter Your Name'
 >
 </Form.Control>
 </Form.Group>
 
 <Form.Group controlId='email'>
 <Form.Label> Email Address</Form.Label>
 <Form.Control
 required
 type='email'
 placeholder='Enter Email'
 >
 </Form.Control>
 </Form.Group>
 
 <Form.Group controlId='password'>
 <Form.Label> Password</Form.Label>
 <Form.Control
 required
 type='password'
 placeholder='Enter Password'
 >
 </Form.Control>
 </Form.Group>
 
 <Form.Group controlId='passwordConfirm'>
 <Form.Label> Confirm Password</Form.Label>
 <Form.Control
 required
 type='password'
 placeholder='Enter Password'
 >
 </Form.Control>
 </Form.Group>
 
 <Button type='submit' variant='dark'>Register</Button>
 </Form>
 <Row className='py-3'>
 <Col>
 Already have an account? <Link to={'/login'}>Sign in here.</Link>
 </Col>
 </Row>
 </FormContainer>
 </Card>
 )
}
export default RegisterScreen
```
 
If all has gone well up to this point you should have an app up that looks like this:
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1654545171/build-react-app-pt-i_ee4noa.gif"/>
 
I think this is a good stopping point for now. In the next post, we will wire up this app to the Django app from the previous post. I think we will end up with some super useful and reusable code for a full-stack project.

Build a React frontend with the API from the previous post

large_9-build_react_app_pt_i.webp

medium_9-build_react_app_pt_i.webp

small_9-build_react_app_pt_i.webp

thumbnail_9-build_react_app_pt_i.webp

9-build_react_app_pt_i.webp

Let's build a React app with user account functionality. Part I

2.17.22
 
I’ve written about building APIs with the Django REST Framework before but for this post I want to share how to actually do it. I am going to walk you through how to set up an API for managing user accounts for a Django project. This API allows for an independently developed frontend to register new users, authenticate them with encrypted JSON Web Tokens, grab specific user data, update that user data and then delete the user account. Since its Django, we get access to the built-in admin dashboard for viewing changes made with the API. Since its Django REST Framework, we get the web browsable UI for the API. And since we are building an API, I suggest using a tool like Postman for testing it. 
I am going to start from scratch here. Below are some bash/shell commands that I start every new Django project with. I should probably mention that this is for Python 3 and up. Type <code style="color:green;"> python -V</code> if you aren’t sure. 
```bash
$ # create virtual environment
$ virtualenv venv
$ # activate venv
$ . venv/bin/activate # if on mac/linux 
$ # install django
$ python -m pip install django
$ # create django project
$ django-admin startproject <project-name>
$ # change into project
$ cd <project-name>
$ # migrate admin and auth to SQLite db
$ python manage.py migrate
$ # create superuser so you can login to /admin
$ python manage.py createsuperuser
$ # follow prompts
$ # start django server
$ python manage.py runserver
```
 
Every Python program should always be written in a virtual environment to keep project’s dependencies isolated from other projects. After the development environment is created and activated, install Django and start a project. That migrate command applies models into the database schema. You use it when you create models and change them. We are using it here to create an SQLite database and applying stock models that Django comes with to it. This allows for access and use of the built-in admin dashboard and the SQLite database will hold the data for the user accounts. After the admin dashboard is created you need to create an admin user to access the dashboard. Django CLI walks you through some basic questions. Now you can finally fire up the development server. In a browser, check out http://127.0.0.1:8000/ or http://localhost:8000/ to see if everything is working so far. You should see a little rocket ship success message. 
Time to install the Django REST Framework. Kill the server in the terminal (Control + C on mac) or in a new window: 
```bash
$ # install django REST framework
$ pip install djangorestframework 
$ # DRF docs suggest the next two dependencies
$ # Markdown support for the browsable API.
$ pip install markdown
$ # Filtering support
$ pip install django-filter 
```
 
Let Django know about the install. In ***project-name/settings.py***, add ***rest_framework*** to ***INSTALLED_APPS***.
 


```python
INSTALLED_APPS = [
 ...
 'rest_framework',
]
```




 
Now start a Django app.
 
```bash
$ python manage.py startapp <app-name>
```
 
Right under rest_framework in ***settings.py***, add the app.
 
```python
INSTALLED_APPS = [
 ...
 'rest_framework',
 'app-name',
]
```
 
In the root urls.py, add a route that points to the app. 
```python
urlpatterns = [
 path('admin/', admin.site.urls),
 path('api/', include('<app-name>.urls')),

]
```
 
Next we set up JWT authentication. JWT (apparently pronounced “jot”) is JSON Web Token. JSON is JavaScript Object Notation. Acronym inception. JWT is a “proposed Internet standard”. It is easy to read because it’s JSON, it’s encrypted so it’s pretty safe and it doesn’t use a database so it’s pretty fast. Simple JWT is a popular plugin to use JWT in Django. Install it in the terminal: 
```bash
$ pip install djangorestframework-simplejwt
```
 
In settings.py, add the ***rest_framework_simplejwt.authentication.JWTAuthentication*** to the list of authentication classes: 
```python
REST_FRAMEWORK = {
 'DEFAULT_AUTHENTICATION_CLASSES': (
 'rest_framework_simplejwt.authentication.JWTAuthentication',
 )
}
```
 
Next, create ***<app-name>/urls.py***. In the new urls.py, include routes for Simple JWT’s TokenObtainPairView (and TokenRefreshView) views: 
```python
from rest_framework_simplejwt.views import (
 TokenObtainPairView,
 TokenRefreshView,
)

urlpatterns = [
 ...
 path('api/token/', TokenObtainPairView.as_view(), name='token_obtain_pair'),
 path('api/token/refresh/', TokenRefreshView.as_view(), name='token_refresh'),
 ...
]

# note: can change the url paths to something like 
path('users/login/', views.MyTokenObtainPairView.as_view(), name='token_obtain_pair'),
```
 
This can get a little tricky because of files with the same name. In the root urls.py, point the app toward the new urls.py. 
```python
from django.contrib import admin
from django.urls import path, include

urlpatterns = [
 path('admin/', admin.site.urls),
 path('api/', include('api.urls')),
]
```
 
Back in ***settings.py***, you can customize the token: 
```python
# https://django-rest-framework-simplejwt.readthedocs.io/en/latest/settings.html
from datetime import timedelta

SIMPLE_JWT = {
 # 'ACCESS_TOKEN_LIFETIME': timedelta(minutes=5),
 'ACCESS_TOKEN_LIFETIME': timedelta(days=30),
 'REFRESH_TOKEN_LIFETIME': timedelta(days=1),
 'ROTATE_REFRESH_TOKENS': False,
 'BLACKLIST_AFTER_ROTATION': True,
 'UPDATE_LAST_LOGIN': False,

 'ALGORITHM': 'HS256',
 # 'SIGNING_KEY': settings.SECRET_KEY, # this was throwing an error
 'VERIFYING_KEY': None,
 'AUDIENCE': None,
 'ISSUER': None,
 'JWK_URL': None,
 'LEEWAY': 0,

 'AUTH_HEADER_TYPES': ('Bearer',),
 'AUTH_HEADER_NAME': 'HTTP_AUTHORIZATION',
 'USER_ID_FIELD': 'id',
 'USER_ID_CLAIM': 'user_id',
 'USER_AUTHENTICATION_RULE': 'rest_framework_simplejwt.authentication.default_user_authentication_rule',

 'AUTH_TOKEN_CLASSES': ('rest_framework_simplejwt.tokens.AccessToken',),
 'TOKEN_TYPE_CLAIM': 'token_type',

 'JTI_CLAIM': 'jti',

 'SLIDING_TOKEN_REFRESH_EXP_CLAIM': 'refresh_exp',
 'SLIDING_TOKEN_LIFETIME': timedelta(minutes=5),
 'SLIDING_TOKEN_REFRESH_LIFETIME': timedelta(days=1),
}
```
 
Now add those views that the new ***urls.py*** point to in ***app-name/views.py***: 
```python
from rest_framework_simplejwt.serializers import TokenObtainPairSerializer
from rest_framework_simplejwt.views import TokenObtainPairView

class MyTokenObtainPairSerializer(TokenObtainPairSerializer):
 @classmethod
 def get_token(cls, user):
 token = super().get_token(user)

 # Add custom claims
 token['name'] = user.name
 # ...

 return token

class MyTokenObtainPairView(TokenObtainPairView):
 serializer_class = MyTokenObtainPairSerializer
```
 
Now we need to set up some serializers. Serializers allow complex data such as query-sets and model instances to be converted to native Python datatypes that can then be easily rendered into JSON, XML or other content types. Django comes with a User model already that we can use. We will import that existing User model and the ModelSerializer from Django REST Framework. 
Create the file ***project-name/app-name/serializers.py*** 
```python
from django.contrib.auth.models import User
from rest_framework import serializers
from rest_framework_simplejwt.tokens import RefreshToken

class UserSerializer(serializers.ModelSerializer):
 name = serializers.SerializerMethodField(read_only=True)
 id = serializers.SerializerMethodField(read_only=True)
 isAdmin = serializers.SerializerMethodField(read_only=True)

 class Meta:
 model = User
 fields = ['id', 'username', 'email', 'name', 'isAdmin']

 # you can create serializer method fields that return back custom attributes

 def get_id(self, obj):
 return obj.id

 def get_isAdmin(self, obj):
 return obj.is_staff

 def get_name(self, obj):
 # passing into built in django field first_name
 name = obj.first_name
 if name == '':
 name = obj.email
 return name

# extending off UserSerializer
class UserSerializerWithToken(UserSerializer):
 token = serializers.SerializerMethodField(read_only=True)
 class Meta:
 model = User
 fields = ['id', 'username', 'email', 'name', 'isAdmin', 'token']

 def get_token(self, obj):
 token = RefreshToken.for_user(obj)
 return str(token.access_token)

 # take that user object and return back another token with the initial response
```
 
Now we can import those serializers into the views.py that we started to set up before the serializers. 
```python
from django.shortcuts import render
from rest_framework_simplejwt.serializers import TokenObtainPairSerializer
from rest_framework_simplejwt.views import TokenObtainPairView
from .serializers import UserSerializer, UserSerializerWithToken

class MyTokenObtainPairSerializer(TokenObtainPairSerializer):
 # @classmethod
 # def get_token(cls, user):
 # token = super().get_token(user)

 # # Add custom claims
 # token['username'] = user.username
 # token['message'] = 'why is the sky blue? why is water wet?'

 # return token

 # commented out function above puts the username and a message encrypted into the access token
 # below function serializes data and makes it accessible in the API, making it easier to grab from the frontend

 def validate(self, attrs):
 data = super().validate(attrs)
 # data['username'] = self.user.username
 # data['email'] = self.user.email

 # changing to for loop to output the data from the serializer instead of adding manually
 serializer = UserSerializerWithToken(self.user).data
 for key, value in serializer.items():
 data[key] = value

 return data

class MyTokenObtainPairView(TokenObtainPairView):
 serializer_class = MyTokenObtainPairSerializer
```
 
Now is probably a good time to set up CORS Headers. CORS is an acronym (a lot of acronyms in tech) for Cross Origin Resource Sharing. This is important when developing an API because you have to control who/what has access to not just the data but the API itself. To control API access, we are going to use the convenient Django-CORS-Headers App.
 
```bash
$ # install library
$ pip install django-cors-headers
```
 
This is also a good time to create or update requirements.txt: 
```bash
$ pip freeze > requirements.txt
```
 
Get back to that familiar settings.py and continue to install/configure the CORS Headers: 
```python
INSTALLED_APPS = [
 'django.contrib.admin',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.messages',
 'django.contrib.staticfiles',
 "rest_framework",
 "corsheaders",
 "api.apps.ApiConfig",
]

# https://pypi.org/project/django-cors-headers/
# so django allows a frontend to connect

MIDDLEWARE = [
 'corsheaders.middleware.CorsMiddleware',
...

]

CORS_ALLOWED_ORIGINS = [
 'http://localhost:3000',
]
# this can be set to anything, including 'all'
# I usually put port 3000 because that is the default for React development servers
```
 
Back in the terminal, fire up the Django server again: 
```bash
$ python manage.py runserver
```
 
At this point most of the set up is complete and we can start testing the API and building the rest of the functionality. With the Django server up and running and if you used my URL routes, you should be able to go to http://localhost:8000/api/users/login/ and view the My Token Obtain Pair View. 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1654017842/mytokenobtainpair_i6usw7.png"/>
 
With this view you can login an existing user. If you are following along here, you have one user, the superuser admin one. You can put your credentials into the HTML form or send raw JSON data right from the browser. Alternatively you can use something like Postman to send that data to simulate how a frontend will interact with the API. 
The JSON data to send to login a user is simply:
```json
{
 "username": "<your-name>",
 "password": "<your-pass>"
}
```
 
Once the username and password are verified the information that we receive back is user account data along with a token that grants access for this user for as long as we customized earlier. That token will also grant access to features that we protect with role permissions.
Now let’s register a new user account for the app. This is cool because users can sign themselves up for your app. In views.py: 
```python
from django.shortcuts import render
from django.contrib.auth.models import User
from rest_framework_simplejwt.serializers import TokenObtainPairSerializer
from rest_framework_simplejwt.views import TokenObtainPairView
from rest_framework.decorators import api_view, permission_classes
from rest_framework.permissions import IsAuthenticated, IsAdminUser
from rest_framework.response import Response
from django.contrib.auth.hashers import make_password
from rest_framework import status
from .serializers import UserSerializer, UserSerializerWithToken

@api_view(['POST'])
def registerUser(request):
 data = request.data
 # print(data)
 
 try:
 user = User.objects.create(
 first_name=data['name'],
 username=data['email'],
 email=data['email'],
 password=make_password(data['password'])
 )
 serializer = UserSerializerWithToken(user, many=False)
 return Response(serializer.data)
 except:
 message = {'detail':'That email is already registered with us.'}
 return Response(message, status=status.HTTP_400_BAD_REQUEST)
```
 
Be sure to add the necessary imports for the decorators. We are also using the Django method make_passowrd() to hash the passwords users create. This protects the passwords from users with admin privileges. To finish this view, wire up the URL path in urls.py : 
```python
from django.urls import path
from . import views

urlpatterns = [
 path('users/login/', views.MyTokenObtainPairView.as_view(), name='token_obtain_pair'),
 path('users/register/', views.registerUser, name='register'),
]
```
 
Now at http://localhost:8000/api/users/register/ you can register a new user by sending name, email and password in Postman: 
```json
{
 "name": "snoopy",
 "email": "snoopy@aol.com",
 "password": "woodstock"
}
```
 
Get logged in user data: 
```python
@api_view(['GET'])
@permission_classes([IsAuthenticated])
def getUserProfile(request):
 user = request.user
 serializer = UserSerializer(user, many=False)
 return Response(serializer.data)
```
 
We are protecting this view with <code style=“color:green;”>@permission_classes([IsAuthenticated])</code>. That means you need to send that Bearer token from the login to access this data. Wire it up in urls.py: 
```python
urlpatterns = [
 path('users/login/', views.MyTokenObtainPairView.as_view(), name='token_obtain_pair'),
 path('users/register/', views.registerUser, name='register'),
 path('users/profile/', views.getUserProfile, name='users-profile'),
]
```
 
Get all users:
 
```python
@api_view(['GET'])
@permission_classes([IsAdminUser])
def getUsers(request):
 users = User.objects.all()
 serializer = UserSerializer(users, many=True)
 return Response(serializer.data)
```
 
This one we restrict to not just a logged in user but the user must be admin. The Bearer token again will authenticate that for us. You guessed it… wire it up in urls.py:
 
```python
urlpatterns = [
 path('users/login/', views.MyTokenObtainPairView.as_view(), name='token_obtain_pair'),
 path('users/register/', views.registerUser, name='register'),
 path('users/profile/', views.getUserProfile, name='users-profile'),
 path('users/', views.getUsers, name='users'),
]
```
 
Delete a user: views.py
 
```python
@api_view(['DELETE'])
@permission_classes([IsAdminUser])
def deleteUser(request, pk):
 userForDeletion = User.objects.get(id=pk)
 userForDeletion.delete()
 return Response('User was deleted')
```
 
urls.py:
 
```python
 ...
 path('users/delete/<str:pk>/', views.deleteUser, name='user-delete')
 ...
 # dynamic value for string value for primary key which is the user ID
```
 
Get user by ID and update user: views.py
 
```python
@api_view(['GET'])
@permission_classes([IsAdminUser])
def getUserById(request, pk):
 user = User.objects.get(id=pk)
 serializer = UserSerializer(user, many=False)
 return Response(serializer.data)

@api_view(['PUT'])
@permission_classes([IsAuthenticated])
def updateUser(request, pk):
 user = User.objects.get(id=pk)

 data = request.data

 user.first_name = data['name']
 user.username = data['email']
 user.email = data['email']
 user.is_staff = data['isAdmin']
 # .is_staff is django admin

 user.save()

 serializer = UserSerializer(user, many=False)

 return Response(serializer.data)
```
 
urls.py should now look like this:
 
```python
from django.urls import path
from . import views

urlpatterns = [
 path('users/login/', views.MyTokenObtainPairView.as_view(), name='token_obtain_pair'),
 path('users/register/', views.registerUser, name='register'),
 path('users/profile/', views.getUserProfile, name='users-profile'),
 path('users/', views.getUsers, name='users'),

 path('users/<str:pk>/', views.getUserById, name='user'),
 path('users/update/<str:pk>/', views.updateUser, name='user-update'),
 path('users/delete/<str:pk>/', views.deleteUser, name='user-delete'),
]
```
 
This completes the CRUD functionality with being able to update user data. If you followed my code then the update url would be ***http://localhost:8000/api/users/update/{id}***. 
This code is available on my GitHub at <a href="https://github.com/Adamhunter108/django-api-login" style="color:purple;"> github.com/Adamhunter108/django-api-login </a>. 
I hope that this helps somebody learn a little about developing APIs or better yet helps somebody out with a project they are working on.

Building a user authentication API with full CRUD operations

large_8-lets_build_an_api.webp

medium_8-lets_build_an_api.webp

small_8-lets_build_an_api.webp

thumbnail_8-lets_build_an_api.webp

8-lets_build_an_api.webp

Let's Build An API

1.11.22 
 
I wanted to write about React and WordPress because these two tools are nearly impossible to avoid with modern web development and it still seems that some people aren’t aware that it is possible to combine these two technologies. Not only is it possible but these two together can be quite powerful for developers. There are several ways to combine React and WordPress. The first method I actually mention in a post from back in June when I was exploring content management system options. With the WordPress RESTful API you can use WordPress as a headless CMS which allows for developing an independent React frontend completely outside of the classic WordPress ecosystem. 
 
I briefly mentioned Frontity in that post. Frontity is an open source React framework for WordPress. They make it super easy to connect WordPress to a React frontend, in fact they even offer several themes to bootstrap a site, much like WordPress proper. Since these themes are built with React, there are plenty of advantages over typical WordPress themes. Some of these pre-built themes come with Redux bundled in. These themes, along with developing your own React frontend have a few more advantages like performance and speed which has a positive impact on SEO. More advantages are scalability and unlimited control over the UI. Since WordPress and React seem to both dominate the web right now, I’d say you could bet your NFT collection that Frontity, along with other React frameworks like Next.js and Gatsby combined with WordPress will continue to grow in popularity. 
 
But what if you need to or want to work within the WordPress ecosystem? I have recently experienced the former and then latter. I recently contributed to a project built out within the WordPress ecosystem and after going down the rabbit hole I have resurfaced with a whole new respect and affinity for the WordPress ecosystem. In the back of my mind I kind of thought WordPress was for people who can’t or don’t code and thought I was above WordPress. It turns out that is quite ignorant. To be fair, I was mostly thinking about WordPress.com instead of WordPress.org. While WordPress.com can and certainly is used by people who have never coded and don’t want to start, if you aren’t afraid of a little PHP and know a little bit about web development, it turns out WordPress.org can be a surprisingly powerful, free and fun tool for creating websites and apps. I noticed that some WordPress developers even use PostgreSQL instead of MySQL. 
 
Plugins are part of what makes WordPress so powerful. The WordPress plugin game is so big, it has become its own industry. These plugins are well developed and maintained and at this point you can find one to help you do almost anything. In reality, there are plugins to contradict most of the advantages I even mentioned in the previous paragraph. There are very powerful SEO plugins and I even found a Redux plugin. 
 
An obvious way to incorporate React into the WordPress ecosystem would be through a plugin. The RectPress plugin is an easy way to embed a React app into WordPress. It allows for use of the familiar npx create-react-app and will connect a local development server into a WordPress theme. That is cool because you can see exactly what you are doing before you even run the build. With this method you still utilize the WordPress API or WPGraphQL to get data to and from the React app. 
 
One of the last ways I want to discuss combining React with WordPress takes advantage of the fact that since late 2018, WordPress ships with an abstraction of React. The WordPress 5.0 update included Gutenberg, which is the name for the new block editor. Gutenberg is actually built using React. So, modern WordPress already contains the entire React and ReactDOM libraries. This allows for writing lightweight React code to be used within the WordPress ecosystem in two primary ways. The first is template based, meaning you can include a React theme into the WordPress ecosystem by adding it to the famous functions.php file. This is great for running site wide components like a header or footer. The other method would be to make your own Gutenberg block/plugin using React and then use the block at will. Now that is cool. This option felt like the most exciting and viable option to use React and to fully take advantage of the power of WordPress. 
 
The gif below is me testing this out by making my own Gutenberg block/plugin out of an MUI React slider. The project that I mention earlier specifically asked for a React slider so that is where I started. 
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1654017849/reactsliderwp_nj7qml.webp"/> 
 
I think it is safe to say that these methods of combining React and WordPress offer some exciting possibilities. As with most things of this nature, choosing how to approach this highly depends on the project and development preference. WordPress and React are both highly respectable in their individual own rights and when combined you can create beautiful, custom content and design with the cutting edge modern tools while being able to deliver products that are comfortable and trusted for all types of users and clients from small blogs to large sites with heavy traffic to SaaS projects.

medium_7-reactwordpress.webp

small_7-reactwordpress.webp

thumbnail_7-reactwordpress.webp

7-reactwordpress.webp

React and WordPress?!?

12.9.21
 
Since the previous post was about backend tech, PostgreSQL (databases) & Python, I figured the next one can be about frontend. I want to explore and compare two super popular frontend design tools, Material UI and Bootstrap. These two tools are for building what most people associate frontend design with, the actual user interface (UI) with the user experience (UX) in mind. These two tools both help people create user interfaces by providing pre-built elements. Or a little more plainly, you don’t have to code EVERYTHING by hand. 
 
Bootstrap describes itself as the world’s most popular frontend open source toolkit. It is an HTML, CSS, JS framework with pre-built elements. Originally called Twitter Blueprint, Bootstrap was initially created by Twitter to help them build faster with more consistency. In 2011 Twitter open sourced it, changed its name and released it to the public. Keeping with the rise in popularity of React, Bootstrap was rebuilt for React as React-Bootstrap. The components were rebuilt from scratch as true React components cutting out unneeded dependencies such as jQuery. In the last couple years jQuery has been hotly debated and is largely thought to be in pre-obsolescence. Note: you can still use Bootstrap without React, I will just be focusing on React-Bootstrap. 
 
Material-UI (or just MUI) is a React UI library that adheres to Material Design principles. Material Design, originally called Quantum Paper, is a design language developed by Google in 2014. Material Design was developed to deliver intuitive, cross-platform design. The Material Design principles try to bring natural or real world laws to user interface design. Natural or real world laws meaning it takes principles for motion, interaction, animation, navigation, typography, shapes, shadows, colors, etc into account. So, MUI is a React component library with an entire elaborate design theory behind it. 
 
A few years ago mobile devices accounted for about half of all internet traffic. Unsurprisingly, that number has continued to grow to around 70%. With about 3.5 billion smartphones in circulation (there’s less than 8 billion humans on Earth right now), it is estimated that people are spending up to an average of 5 hours a day using their smartphones. It is not unreasonable to assume the recent pandemic has helped boost these statistics but for some people, smartphones are how they access the web. I’m not just talking about third world/developing countries but giant swaths of demographics all over. Over 95% of active Facebook traffic comes from mobile devices now. Do your parents even have a desktop anymore or just tablets? Are you reading this on your phone right now? With these massive numbers come the general dismissal of sites and apps that are not mobile friendly. If somebody has a negative mobile experience, the chances of them recommending or returning to the site or app drops significantly. 
 
It makes sense that both Bootstrap and MUI both take a mobile-first or responsive-design approach. Responsive web design is making sure your site or app renders well on a variety of window and screen sizes. How does Bootstrap and MUI achieve this? With responsive grid systems. They both use a similar 12-grid system that helps elements on a page automatically rearrange and resize. Bootstrap uses rows, columns and containers and MUI uses columns, gutters and margins. Both Bootstrap and MUI also have excellent browser compatibility. Since different browsers render code differently, browser compatibility should always be taken into consideration. 
 
Some key differences between Boostrap and MUI are their dependencies, development speed and customization. Bootstrap is a large framework that comes with a lot of code and scripts. This large framework can be a system hog, dampening page performance and draining batteries. MUI on the other hand uses React components that are independent of each other so you can use only what you want/need. While it is possible to get into the Bootstrap code and weed out components you are not using, it is tedious and time consuming and defeats one of Bootstrap’s big selling points, development speed. Bootstrap is known for creating quickly using reusable code and components. Customization ties into development speed and is probably where Boostrap and MUI diverge the most. While Bootstrap components can be customized they sometimes get criticized for looking a little stock where MUI offers seemingly endless customization. The actual code to customize MUI components can become quite involved. 
 
Who uses which? Bootstrap: Twitter (obviously), Airbnb, Apple Music, Dropbox, Spotify, Lyft. MUI: Amazon, Nasa, all Google products. Which should you choose? Both are completely professional and valid options. It is completely up to you and your project. Or maybe don’t choose at all, it is entirely possible to just use both at the same time. If you are going to mix the two you might want to check out MDB - Material Design for Bootstrap which is a single React library that tries to give you the best of both worlds. Bootstrap and MUI aren’t the only players in town either. Other industry heavies to explore are Chakra UI, Blueprint UI, and Ant Design; all with unique features and use cases.

large_6-bootstrap_mui.webp

medium_6-bootstrap_mui.webp

small_6-bootstrap_mui.webp

thumbnail_6-bootstrap_mui.webp

6-bootstrap_mui.webp

Material UI VS Bootstrap

10.10.21 
 
Since Django is my preferred backend framework, PostgreSQL has followed as my preferred database. Even though Django connects to a SQLite database out of the box, PostgreSQL (or just Postgres) is one of four other officially supported databases. The others being MySQL (owned by Microsoft), MariaDB (which is a fork of MySQL), and Oracle. Since Oracle is notoriously expensive to run, Postgres is probably the most powerful and versatile database officially supported by Django. Well, technically PostgreSQL is an object relational database management system (RDBMS). The word database is used a little ubiquitously; a database can really refer to any collection of data, not even necessarily on a computer and a data base management system is software that allows you to interact with a database. 
Let’s circle back to Django’s stock database, SQLite. SQLite is a file based, serverless database. As the name suggests, it is super lightweight. Being lightweight comes with advantages and disadvantages. Advantages include ease of use, especially with Django. There is a small footprint, no configuration, no external dependencies and is actually a great solution for applications that read and write files to disk directly. A few disadvantages include scalability, security, user management and concurrency. This is where Postgres can step in. 
A little background – Postgres has been around for 30 years and is open source which means there is a tremendous community of developers supporting it and keeping it modern. It is also flexible and scalable enough for it to be used for free in testing and small app development and to be used in production as the primary database for new startups and tech giants like Apple, Instagram and Reddit. It is also fully ACID (database integrity standards) and SQL compliant, where technically MySQL is not. 
While MySQL remains the more popular and more widely used RDBMS, Postgres does outshine in a few more ways. MySQL can be more costly to run and does reserve some features and plugins for proprietary licenses. Postgres supports additional data types too. Postgres and MySQL both support string, numeric, date and time data types but Postgres extends support for JSON, network addresses, geometric shapes, text searches, currency and more. 
Developing with Postgres also means options as far as clients go. You can use the command line to query the database using a tool like psql or you can go the graphic user interface (GUI) route and use cross-platform software like Postbird or the more robust and popular PgAdmin (see stock photo below). In addition to those tools Postgres even features a native Mac OS app. 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1654017841/pgadmin_ymodxc.webp"/>
 
In order to use Postgres with Django (or Flask) you will have to <code style="color:green;"> pip install psycopg</code>. “Psycopg is the most popular PostgreSQL adapter for the Python programming language” says their website. That could be because the official Django documentation states that Psycopg 2.5.4 or higher is required. Once the adapter is installed to the project, connecting a Django backend to a live Postgres server is just a matter of editing a few lines in the settings.py file. 
I hope that comparing and contrasting PostgreSQL to SQLite and MySQL helped to shine some light on these popular databases.

Python and the world's most advanced open source database

medium_5-postgres_python.webp

small_5-postgres_python.webp

thumbnail_5-postgres_python.webp

5-postgres_python.webp

PostgreSQL

8.16.21
 
Redux seems to be slippery for a lot of newer developers to get a firm grasp on. At a quick glance some definitions and examples can seem both very vague and very complicated at the same time. Redux comes with an entire new vocabulary that can be a little intimidating as well – we’ve got a store, actions, dispatchers, reducers, thunks… all for managing application state. Even the term ‘state’ might be a little foreign to developers who primarily develop with backend technologies. Let’s simply break down some of these terms and lift the veil of obscurity on Redux. 
 
Let’s clear up that state issue before anything else. I found an eloquent quote from Stack Overflow: “An application’s state is roughly the entire contents of its memory.” Application state is data that is stored in memory on the server or locally. Using application state is useful because it is faster than storing and retrieving information from a database. 
 
Ok now that everybody is clear on what state is – Redux is an open-source JavaScript library for managing and updating application state. Redux is not a React specific library but I will be talking about it in the context of React. Redux is not really for state between components but for global or app wide state and works best with applications that have a large amount of global state that is accessed by many of the application’s components. A main goal of using Redux is scalability for managing these large amount of global state. 
 
 
Even though Redux is not React specific it does have an official Redux UI binding library for React, aptly called React Redux. On top of Redux and React Redux, there is a third dependency that should be installed if utilizing Redux in a React application, Redux Thunk. Redux Thunk allows for asynchronous requests from the store, which brings us to our first new Redux specific vocabulary word. 
 
 
**The store** – the heart of Redux is the store. The store (there should be only one per Redux application) is an object that holds the application’s state tree. The store holds the state. The reason that is important is because the store has the ability to update the global state of an application which would affect elements of the application’s UI. The global state in the store should never be accessed directly, that is done through functions provided by the store. While researching this I came across an analogy that I will paraphrase. The store can be thought of like the vault in a brick and mortar bank. In order to access contents of the vault, you must fill out a withdrawal form and speak to a teller, maybe a manager if you want large amounts of content. The point being, you can’t just walk right up to the vault. Before we get into those functions to access the vault, now would probably be a good time to mention the one way data flow of Redux. 
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1654016793/ReduxDataFlowDiagram_lw0nlb.gif"/> 
 
Straight from the official Redux docs. It’s not stealing if my CodeCademy Pro 10 hour Redux certification course can use the identical gif (very humble flex). So the data flows from state to view to action back to state and so on. 
 
 
**Actions** – the only way to get data into the store. An action is just a JavaScript object that represents an intention to change the store’s state. It is an event that describes something that happened in the application. An action has only one required field (even though it can have many more and the structure is customizable) and that is type. The type field should be a string that gives the action a descriptive name. The standard naming convention is “domain/eventName”, where the first part is the feature or category that this action belongs to, and the second part is the specific thing that happened. An action object can have other fields with additional information about what happened. By convention, we put that information in a field called payload. 
 
The way state gets changed is through Reducer functions. Reducers are functions (that accept actions) that are responsible for passing state to components. You can think of a reducer as an event listener which handles events based on the received action ( or event) type. So, a reducer takes in current state and an action and returns the new state based on the action it receives. 
 
**Dispatchers** are Redux store functions that trigger events in an application. They let the store know about something that happened. 
 
Finally we have the weirdest Redux vocabulary word – **Thunk**. As in the past tense for think, something like “I already thunk about it”. A thunk (not exclusive to Redux btw) is a subroutine used to inject a calculation into another subroutine. Or a function that is used to delay a computation until it is needed by the application. By default, JavaScript functions are thunks since they hold information and can be executed any time or passed to another function (to also be executed at any time). So, in Redux thunks can be used to hold asynchronous logic that interacts with the Redux store. 
 
Without going too deep into the rabbit hole, that is essentially Redux at its core. Developing with Redux gives you access to some cool dev tools for monitoring, debugging and testing application state changes. 
 
I have been working on an e-commerce site. For this project I am using Redux to manage the global state of users data, products, orders and as shown above, shopping cart items. In this case I am utilizing the local storage for the state. 
 
Without getting into specific code, I think that is a pretty comprehensive conceptual introduction to Redux. We'll get into the code in another post.

large_4-redux.webp

medium_4-redux.webp

small_4-redux.webp

thumbnail_4-redux.webp

4-redux.webp

Redux

7.23.21
 
I was recently asked to help develop a project and one of the technologies used for the project is GraphQL. GraphQL is something I have read lightly about but never dove in. So I did to familiarize myself with it. 
 
What is GraphQL? 
“GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.” – <a href="https://graphql.org" style="color:purple;">graphql.org</a> 
So, GraphQL is a query language for APIs, NOT databases. GraphQL claims to be the new API standard, providing a more efficient, powerful and flexible alternative to REST. It was developed and open-sourced by Facebook and is now maintained by a large community of developers. GraphQL enables declarative data fetching where a client can specify exactly what data it needs from an API. Instead of multiple endpoints that return fixed data structures, a GraphQL server only exposes a single endpoint and responds with precisely the data a client asked for. 
 
Since GraphQL is API focused, it is usually thought of as frontend technology but the API is still implemented on the backend (server side). GraphQL servers are available for many languages (Haskell, JavaScript, Perl, Python, Ruby, Java, C++, C#, Scala, Go, Rust, Elixir, Erlang, PHP, R, D and Clojure). I decided to dive in using Python so I could experiment using Django as my framework. Since choosing to work with Python and Django I also utilized Graphene, which is a Python library for building GraphQL schemas/types using a code-first approach. Code-first meaning, instead of coding in GraphQL SDL (Schema Definition Language), you can code in Python. Schema-first would be the contrasting approach (i.e. Apollo for JavaScript and Ariadne for Python). Graphene also has a Django specific module. 
 
A really cool thing about developing a GraphQL backend API is that it allows developers to focus on describing the data available rather than implementing and optimizing specific endpoints. It allows this through a schema and resolve functions. In GraphQL, a Type is an object that may contain multiple fields. Each field is calculated through resolvers, that returns a value. A collection of types is called a schema. The schema is a model of the data that can be fetched through the GraphQL server. It defines what queries clients are allowed to make, what types of data can be fetched from the server, and what the relationships between these types are. The schema tells the server what queries clients are allowed to make, and how different types are related but they do not handle where the data comes from. Enter the resolve functions. Resolve functions specify how the types and fields in the schema are connected to the backend(s). GraphQL resolve functions can contain arbitrary code, which means a GraphQL server can to talk to any kind of backend and any kind of database. Another really cool feature of GraphQL is that no matter how many backends you use, all the client will see is a single GraphQL endpoint with a simple, self-documenting API. 
Another big feature of GraphQL is the integrated, interactive in-browser IDE, GraphiQL. See directly below. 
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1654017839/graphql2_bhwaat.png"/> 
 
GraphiQL provides a a split window interface for queries on the left and results on the right. It also provides a GraphQL documentation search feature. It is also built with React which was not surprising to discover. Above is an example of what a query of the GraphQL server looks like and below is mutating (sending data to) the server. 
Those initial links that were queried were originally created with Django. Using Django has other advantages like user authentication. Creating a schema class in Django, you can create users through GraphiQL. Using the django-graphql-jwt library you can implement JWT (JSON) tokens which is the more modern method of authenticating users. 
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1654017839/graphql3_brmiea.png"/>
 
It’s pretty to easy to see why these GraphQL APIs are so popular, especially when thought of in the context of frontend development. Being able to specify exactly what you want out of an API means saving on payload size which means saving on bandwidth which also includes minimizing round trips to the server which means more saving on bandwidth (plus many, many more advantages) which equals GraphQL providing the natural evolution of the REST API.

large_3-graphql_python.webp

medium_3-graphql_python.webp

small_3-graphql_python.webp

thumbnail_3-graphql_python.webp

3-graphql_python.webp

GraphQL & Python

6.7.21
 
For continuity, I would like to start this post off by mentioning despite the previous post exploring several CMS technologies, I ultimately did choose to use tried and true WordPress for a project that I hope to deliver this week. According to… the internet (I googled it) about 65% of all websites on the internet use WordPress for CMS. Another wild purported fact, 40% of all websites on the internet are actually WordPress sites. For this project, WordPress was actually perfect for me as the developer and the client so I didn’t fight it. 
I wanted to write a little about Django and specifically Django REST Framework. I personally love developing with Python and Django specifically. I am not alone here on the Python/Django bandwagon – Instagram, Spotify, Pinterest, DropBox, NASA, Reddit, Udemy, Robinhood, all use Django (Most of them use React on the frontend too). One of the most powerful features Django has is its ORM, or Object Relational Mapper. In other words, you can use Python instead of SQL to create, query and modify databases. Developing the frontend you can use the Django Template Language out of the box, which is great for slipping a variable or some logic into some HTML but is ultimately a little limiting. A much more modern approach would be to develop the frontend independently with tools like React. Scalability and speed are among many more advantages this method provides. 
If you are like Instagram and want to use Django as the backend of a project and connect it to a React frontend UI, one of the best ways to connect them is to have Django serve up an API. Enter the Django REST framework. Django REST framework is a toolkit for building APIs and has some impressive features such as Oauth1(& 2), serialization for aforementioned ORM data sources and a very cool web browsable API. The web browsable API is an interface where you can easily view your API instances and perform all CRUD (Create, Read, Update, Delete) functions. You can view and edit the raw JSON data or the more userfriendly HTML form. Check out the screen cap below from a recent project. 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1654017843/rollinsquote_ziff7r.png"/>
 
Building these API views can be accomplished with just a few lines of Python code. There are class based views and function based views. Whichever method suits your project best you will have to identify some similar information such as specifying the type of HTTP method or action you want to perform. In function based views this can be accomplished by specifying the method in the API view decorator for the function: for example <code style="color:green;">@api_view([‘POST’])</code> . The decorator defaults to GET if left blank. Another decorator that Django REST framework provides that I think is extremely useful is <code style="color:green;">@permission_classes()</code>. With this decorator you can protect certain API views by allowing only authenticated users access. To utilize JWT (JSON Web Token) authentication, a very common approach with Django REST framework would be to use the Simple JWT library. 
Speaking of JSON data and developing with Python, I’d like to mention my preference for pipenv. Pipenv describes itself as “a tool that aims to bring the best of all packaging worlds (bundler, composer, npm, cargo, yarn, etc.) to the Python world.” It does this by handling the developer dependencies with a Pipfile, think requirements.txt, and a Pipfile.lock file which is JSON and like the name suggests, handles the virtual environment. It’s very cool and familiar especially if you use npm or yarn on a regular basis. 
*December 2021 addendum: Regarding that entire last paragraph, I have found pipenv to be a little limiting and have gone back to using tried and true virtualenv and requirements.txt for dependencies.

small_2-DRF.webp

thumbnail_2-DRF.webp

2-DRF.webp

Django REST Framework

5.25.21 
 
Like probably most software developers early in their careers, I have been doing some freelance work. When I first started I had to dive into the world of CMS to figure out how to deliver a project that I coded. 
 
WTF is CMS – CMS is what most people call the backend of their site, it’s the admin dashboard where you can upload things and make posts and traditionally even features the actual frontend that combines the data from the database with HTML.
   
There are two types of CMS to choose from, on-premises and cloud based, and WordPress is probably the most well known for both kinds. I won’t get into WordPress here, let’s go beyond it. To go beyond traditional WordPress/CMS, let’s get into headless CMS. 
 
WTF is headless CMS – headless CMS is a backend that makes content accessible via a RESTful API. What does that mean and why is it cool? If a full-stack website were anthropomorphized into a robot or android or something, headless CMS allows you to chop off the ugly old head that was designed in the late 1990’s or something and build a fancy new one with whatever modern tools you like. In this analogy, the spinal cord would be the RESTful API that allows the new fancy head to still work with the old body.   
 
One of my preferred modern tools to make new heads for my robots is React. With a headless CMS, you can make a fancy React app and connect it back to your CMS with an API. Let’s start with Frontity. Frontity touts themselves as THE React framework for WordPress. For the record, you do not have to use a framework however that would require manually coding out many lists of tasks, routing, server rendering, and data retrieval from WordPress. You can do that if you have the time and interest in it but using tech like this often reminds me about reading that Tesla uses Stripe as their payment processing platform. Telsa, you know Elon Musk, that guy, who invented PayPal, he likes Stripe and uses it instead of his own software. Anyway, Frontity seems like a great solution for using React with WordPress CMS.   
 
If you want to move away from WordPress and still use React, Strapi looks like one of the more popular and best options. Full disclosure, I did come across a Strapi vs Sanity debate. To not splinter too far into different rabbit holes, let’s focus on Strapi. Strapi call themselves “the next-gen headless CMS, open-source, javascript, enabling content- rich experiences to be created, managed and exposed to any digital device.” The sub-reddit calls it “The most advanced open-source Content Management Framework to build a powerful API with no effort.” I copied and pasted that because I found it to be true. Within just a few minutes using their documentation I had an API up and running, see pic directly below.  
 
<img src="https://res.cloudinary.com/dwvlpyo5f/image/upload/v1654017973/strapi_ah4wn5.png"/> 
 
Naturally, the rabbit hole does not stop with WordPress, Frontity, Strapi or even React at all, in fact WordPress is all PHP anyway. I consider myself a Python dev and specifically find Django to be incredibly powerful. Django comes with an admin interface out of the box but is not considered to be CMS. There seem to a few good Python/Django CMS options, the top two being Wagtail and Django-CMS (runner up: Mezzanine). Wagtail appears to be a little more popular, probably largely due to the fact that Django-CMS is complex and probably overkill for a lot of projects. They can both be integrated with existing Django apps and are both loaded with features. Using Django-CMS or Wagtail means developing fully in Python instead of using PHP which will also probably mean better security, more customizable, higher speed over time, better scalability and personally means I get to develop in a preferred language.

small_1-CMS.webp

thumbnail_1-CMS.webp

1-CMS.webp

Content Management Systems

blog

writings and musings