Let me walk you through an experience of mine that I now consider debugging hell. I’m writing some API request - maybe I test it in Postman, maybe I don’t. When I run my app and test out the functionality with said API call, you’ll be surprised by this part; it doesn’t work. So I’ll print/console.log the data from the frontend. Maybe I tried to access the data on the wrong object/method, or I misspelled the key name. Maybe it's just not coming through from the API. If none of those reasons, is the URL correct? …
In this article, I’ll assume you’re familiar with Django, Django Rest Framework, React, and a little bit of Docker and Nginx. However, I should state I’m quite new to Docker and Nginx. I’ll also assume you have Python, Pip, Node, and Docker set up. I’ll be using Pipenv, but if you want to install your Python dependencies globally, I guess I can’t stop you. My goal is to show a development set up. I recently worked on using Django session authentication with a Single Page Application (SPA) and Django Rest Framework.
I recently attempted to authenticate users on a React…
If you’re not familiar with building a GraphQL Server, it requires two things: resolvers and type definitions. Put simply, resolvers are the functions that execute your API calls, and type definitions are where you define what goes into (arguments) and what gets returned by your resolvers, these then are combined to create your GraphQL schema.
The standard way of creating these two things is to write out the type definitions, for example, saying I have one query that will return all my users, which are objects with a username (string), id (Int), and one mutation to change the users username.
If you want to know why you should follow this tutorial, read my previous article, which details the benefits of using this stack. It’s a high-level explanation with gifs showing off the workflow benefits. You can find it here:
(There are three headings in the article; “Apollo VSCode Extension: Ensuring Our API Calls Are Without Errors” (2nd) and “Apollo-Client + GraphQL CodeGen: Providing Full Type-safety When Sending and Receiving Data From the API” (3rd) are relevant to this tutorial)
I recommend reading my article above if you’re not familiar with Apollo and GQL-Codegen, as there are specific (very beneficial), features…
In my last article, I wrote about using the stack in the title to severely reduce the chance of making a mistake while you’re developing. If you want to see some kick-ass features the tech in the title can bring, give the below article a read.
This will be a step by step tutorial for getting a project with the workflow features in that article setup.
You need to know GraphQL and TypeScript to follow along with this tutorial. All the other tech I’ll be walking you through.
Find the code for this article here (the branch “just backend” is…
I’ll start by saying I have about a year and a half of experience working with Django every day. I also have experience with Express, which makes me qualified to write this article, which provides many comparisons between Django and lightweight frameworks. I discuss in this article the scenario of starting up a new project with a frontend framework (I’ll reference React, but you can pretend it’s spelt Angular if you want) and the pros and cons of using Django instead are. I also discuss using Django with microservices and WebSockets.
I’ll try to keep any biases I may have…
I recently wanted to deploy React with a Django backend for my personal website. I also wanted to run the website on a single Heroku Hobby Dyno for $7 a month. So in this series, I’ll be covering the process of getting Django to serve to React and then deploying to Heroku.
All I’ll be covering in this article is how to get Django serving React in development.
You can find the code here.
Currently studing Business Information Technology at Queens University Belfast