DEV Community: Shannon W

Setting Up a GraphQL API With Strapi

Shannon W — Wed, 08 Jan 2020 02:06:00 +0000

Original post from series "Building an App with Gatsby and Strapi"

Who is this post for? Each post in the series is loosely dependent on each other. So you can follow any post in any order you like. Posts were made this way so you don’t have to read all the previous ones to follow along.

The goal of this post is to explore Strapi’s GraphQL API in regards to:

setting up the API,
setting up API permissions,
documenting and testing API endpoints.

Setting Up

To begin, you will need to install the GraphQL plugin from the Marketplace.

Once installation is finished, restart Strapi.

Setting Up API Permissions

Similar to setting up the REST API, we will need to define who has permission and to what actions. For example, let’s look at the Page content type and give the Public role permission to call count, find, and findone actions (actions are simply the functions used by the controller to perform business logic).

Step 1 – Ensure the content type is defined as needed

Step 2 – Go to Roles & Permissions and select the Public role

Step 3 – Give permission to use the actions

Documenting and Testing the API

Strapi automatically provides a GraphQL playground at /graphql. So if you are running Strapi locally, it can be found at http://localhost:1337/graphql, otherwise, it’ll be located at http://<website-domain>/graphql. From here you can explore the available schemas, type details, arguments, and test queries using the editor.

Setting Up a REST API With Strapi

Shannon W — Sun, 05 Jan 2020 01:37:46 +0000

Original post from series "Building an App with Gatsby and Strapi"

The goal of this post is to explore Strapi’s REST API in regards to:

setting up the API,
setting up API permissions,
documenting and testing API endpoints.

Setting Up

Okay, so far the post is a bit misleading… Strapi automatically generates content API endpoints for CRUD (create, read, update, delete) operations when you create or modify content types 🙂 So we don’t have to worry about this step!

Setting Up API Permissions

Before we can use the generated API, we will need to define who has permission and to what actions. For example, lets look at the Page content type and give the Public role permission to call count, find, and findone actions (actions are simply the functions used by the controller to perform business logic).

Step 1 – Ensure the content type is defined as needed

Step 2 – Go to Roles & Permissions and select the Public role

Step 3 – Give permission to use the actions

Documenting and Testing the API

There are multiple ways to test this, but for this post I recommend is using Swagger UI. It’s a nifty tool that automatically generates documentations for REST APIs. To set up, run the following command in your terminal in the root folder of the strapi instance.

   npm run strapi install documentation

Restart Strapi. A new UI section is then created to manage the documentation. Here you can access the documentation, test responses, and restrict access to the documentation.

Getting Started With Gatsby and Strapi

Shannon W — Fri, 03 Jan 2020 01:35:31 +0000

Original post from shannonwilliams.io

The goal of this post is to allow anyone to quickly understand how to get up and running with Strapi and Gatsby. This is for anyone who need to:

understand how they work together,
get a project quickly up and running.

Why Use Strapi and Gatsby Together ?

What is Gatsby? Gatsby is a generator framework for building sites built using ReactJs. It has built in client-side routing (react-router), local-state management (Redux), plugins, theming and various other APIs for personalizing the app’s behavior. I recommend checking out there official documentation and comparison with other frameworks.

What is Strapi? Strapi is an open-source Headless CMS, built on NodeJs, that makes managing content easy. It’s built with developers in mind with things like, automatic creation of REST and GraphQL APIs, admin UI for managing content, authentication, files, and making it easily extensible with plugins and custom controllers and services. I also recommend reading the Strapi official documentation.

How They Work Together? Simple, Gatsby will be used for building a web app in React, which will make API calls to Strapi for resources.

Setting Up Gatsby

If NodeJs and NPM are not downloaded and installed, you can download them here. Follow the installation wizard and you’ll be finished in a few minutes.

Open a terminal (Mac OS) or command prompt (Windows), and install the Gatsby command line tools (CLI):

   npm install -g gatsby-cli

Navigate into your directory of choice

   cd <replace-with-desired-directory>

Create a new site:

   gatsby new <replace-with-site-name>

Navigate into your site’s folder:

   cd <site-name>

Start the site in developer mode:

   gatsby develop

Now within a browser you can enter localhost:8000 (The default port is 8000).

Setting Up Strapi

cd into the directory where you want the Strapi instance to be.

   cd <replace-with-desired-directory>

(Option 1) Install and run Strapi – without connecting to database (Use SQLite).

   npx create-strapi-app <project-name> --quickstart

If successful, Strapi will begin running and you can begin configuring your admin account at http://localhost:1337/admin.

(Option 2) Install and run Strapi – with a database.

   npx create-strapi-app <project-name>

Follow the in-terminal setup wizard for connecting to your database. Should look similar to this:

Once installation is finished, cd into the new directory:

   cd <replace-with-desired-directory>

Start Strapi in development mode:

   npm run develop

If successful, Strapi will begin running and you can begin configuring your admin account at http://localhost:1337/admin.

Wrapping Up

That’s it ! Now you can begin developing your client app with Gatsby and begin managing content with Strapi.

Full Stack Development vs Headless CMS vs Traditional CMS

Shannon W — Sun, 29 Dec 2019 22:13:47 +0000

Original Post

Which one is better?

Like most of us, I like to spend my time finding ways to improve development time while still producing high-quality apps. Lately, there have been increasing interest and popularity in using a Headless CMS. But how does it differ and what are the benefits from traditional development and a Traditional CMS solution?

Hopefully this post shed some light and serve as a guide for your next project :)

(Tip – There’s a TL;DR; at the end of this post)

To get a more detailed understanding, we should look common pieces in detail using actual examples such as .NET Core based stack, Strapi (Headless CMS), and WordPress (Traditional CMS):

So What’s a Headless CMS? In general, a Headless CMS is a management solution that is designed and built for simply managing the structure and access of content for multiple apps. Compared to a Traditional CMS, it’s a Headless CMS + front end management.

So how much development work are we looking at?

What percentage developers have to build/focus on typically look something like this:

UI

.NET Core: Whatever UI framework preferred.

Strapi: Whatever UI framework preferred.

WordPress: You can use the inbuilt UI management tools for theming, and configuring the layout of pages and posts for a website. Alternatively, it has a REST API for retrieving posts, pages, categories, tags, etc. with your preferred UI framework. The only caveat is that the API only returns content in HTML. So you need to consider that for front-facing web, mobile, and desktop apps.

Content Management

.NET Core: Unless you build a solution, you will have to define entities/objects/content types by defining classes and relations and integrating a data access technology like Entity Framework Core.

Strapi: Admin screen for defining entities/objects/content types and relations.

WordPress: Supports making pages, posts, categories, tags, by default. You will have to get a plugin or make your own for any additional content types.

Testing

.NET Core: You have to build unit tests and integration tests using xUnit or MSTest for APIs and any other server-side code you want to be tested. You are also free to use any client-side/UI testing tools according to what languages you’re using.

Strapi: No need for creating tests for server-side code. At most, you may want to manually double-check definition of content types, data stored, and roles and permissions just to be sure. You still need to focus on UI tests.

WordPress: You’ll have to focus on testing plugins to make sure updates don’t break anything. Helpers like PHPUnit and WP-CLI comes in handy.

APIs

.NET Core: Will have to architect and program REST or GraphQL API using data access technology like Entity Framework Core for connecting to a database, along with defining entities/objects/content types using classes.

Strapi: Platform automatically creates a REST and GraphQL API once you create content types using the admin UI.

WordPress: Automatically has a REST API to retrieve content. If needed you can extend the API endpoints.

Roles and Permissions

.NET Core: Typically you would use a library like Identity Services for SSO and regular user authentication (email and password). Then you will have to include authentication & custom permission checks on each request to a content resource.

Strapi: Admin UI section for managing roles and permissions with interactive with different content types.

WordPress: Typically only provides the below:

Subscribers can read comments/comment/receive newsletters, etc. but cannot create regular site content.
Contributors can write and manage their posts but not publish posts or upload media files.
Authors can publish and manage their own posts, and are able to upload files.
Editors can publish posts, manage posts as well as manage other people’s posts, etc.
Administrators have access to all the administration features.

– taken from WordPress

Database

.NET Core: Typically a developer would use Migrations if using EF Core and the appropriate data provider library for the respective SQL database. It’s up to developers, or database admin to manage performance at the database level.

Strapi: Upon setting up, you’re given the option to choose which database to use:

MongoDB >= 3.6
MySQL >= 5.6
MariaDB >= 10.1
PostgreSQL >= 10
SQLite >= 3
It’s up to developers, or database admin to manage performance at the database level.

WordPress: Limited to only MySQL. It’s up to developers, or database admin to manage performance at the database level or acquire a plugin to help.

Email Notifications

.NET Core: Can implement this via an on-premise mail server, or external service. Can implement this in code base where necessary.

Strapi: Can use the email plugin to trigger sending emails using services like Sendgrid on custom controllers or services.

WordPress: Chances are you can easily get a free plugin to send emails. All you need to do is to provide mail server settings or external service account info (if using a service like Sendgrid).

SMS/MMS Notifications

.NET Core: Can implement this via external service. Can implement this in the code base where necessary.

Strapi: Based on their documentation, there’s no plugin to send SMS or MMS. However, nothing is preventing you from using a NodeJs SDK to send SMS/MMS notifications.

WordPress: Again, there’s probably a plugin for this. Otherwise, you’ll have to create one. In both cases, an external SMS/MMS provider account (like Twilio SMS) details are required.

Documentation

.NET Core: You can use Swagger for REST API documentation. There are also various free and paid solutions for providing documentation for both server-side and client-side apps. The choice is yours.

Strapi: It also uses Swagger for Strapi’s REST API documentation. The official documentation also addresses API endpoints that are generated for content types. As with any stack, you will have to find a free or paid solution for documenting any client-side app.

WordPress: Can find a plugin that uses Swagger to document WordPress’ REST API. The official documentation also addresses API endpoints that are generated for content types. As with any stack, you will have to find a free or paid solution for documenting any client-side app.

Cost

.NET Core: Depends on the hosting providers’ plans, and fees from 3rd party services.

Strapi: Depends on the hosting providers’ plans, and fees from 3rd party services.

WordPress: Depends on the hosting providers’ plans, and fees from 3rd party services, and paid plugins.

Fixing Bad Code… >_<

.NET Core: Can be found within the UI project, API, and perhaps some SQL. Still…. it depends on the situation. A developer may have been working on the codebase before you and may not have done such a great job choosing and sticking with software design patterns…. or requirements have changed which makes the existing code redundant. To make it worse, the codebase might be huuugee! No matter the reason, dealing with bad code sucks most of the time.

Strapi: You may find bad code within a custom controller, services, plugins, and within the UI project’s codebase.

WordPress: Can be found within plugins and event custom Js snippets for posts or pages.

TL;DR;

The truth is, it depends on the requirements for the app and the vision. If you just want a blog, WordPress is the way to go. But if you want a solution for managing content for various apps, blogging, and other various things, a headless CMS or full-stack development could be feasible.

You see or feel something should be updated? Please reach out and let me know! It’ll be awesome to hear your feedback on this.

Choosing a Programming Stack

Shannon W — Sat, 28 Dec 2019 16:05:54 +0000

Picking the right development stack for a project can be difficult, especially if you are learning as you go. Lately, I have been playing with a few Headless CMS. Sadly, I find some didn’t quite cut it. Realizing this inspired me to write this post. Whether you working on a new innovative project as a freelancer, in-house developer, or just for fun, below are factors to consider.

Knowing The End Goal

Start off by understanding a high-level overview of the main successful user flow. Easy enough. Afterward, go into more details as to the workflow, but not too low where you begin speaking about UI designs. That’ll be a limiter throughout development.

Then you will have to pry deeper to foresee points of failure and establish a correction workflow for them. Correction workflows are basic steps of the user (or app) that will take if something goes wrong and how it’ll be rectified. Keep in mind that you may need to also do correction workflows for your correction workflows… Going through workflows with a client will help him/her to understand the complexity of work.

Establish deadlines and budget you have. If these aren’t established before development, then later down, “something” can happen and may force you to take shortcuts. This can be good or bad depending on how it’s handled. As for deadlines, you may set weekly, bi-weekly, or monthly milestones. Either case, a good understanding of the technology stack being used is needed to balance user deadlines and how long it’ll take to build features. With that said, you may have to come back to this step after addressing the below factors.

Documenting these will help keep development on track and to provide a clear picture of where you are and where you need to be.

Development & Maintenance

Cost, cost, cost, cost… In the end, if not enough money is there, then a number of things can easily fall apart. You’ve got to support yourself and your family, your client needs the money to survive, support the application’s infrastructure maintenance costs, fund future development, etc.. At least a cost-benefit analysis should be done.

No matter the environment, there must be an efficient way to debug and reproduce bugs as they happen. Not saying you are a bad programmer! But they will happen, and if you aren’t able to fix the issue in a timely manner, then fingers are typically pointed to developers. While the blame game works itself out, you can focus on being the hero and fix the bug.

You can’t forget about security! By default, all modern applications need to be built in a way that does NOT prone to vulnerabilities listed in OWASP Top Ten. To the very least, your tech stack needs to be able to defend against them. Otherwise, the technology is not mature yet, or you just haven’t found a way yet. Keep in mind that you should not ignore the 3rd party libraries/packages being used!

What does development look like? This is up to you. Loosely typed languages like NodeJs are fun for small projects. The trouble, however, creeps in as the code base grows larger over time. Type checking, IntelliSense tools, etc. are not as helpful as for strongly typed languages like C#. Therefore, it takes longer to debug. If this is the case for you, then you should use a different language or just allocate more time within estimates for debugging. Again, you also have to consider what working with 3rd party tools will be like. To see a few more factors to consider, read this quick post

One language or framework may not always be best for the project, multiple may be needed. After looking at the trade-offs you may decide that using DotnetCore would be best for building an API and Python for web scraping jobs. The only downside is that you will have to manage runtime environments, SDKs packages, etc. for both in development and production.

Must have strong documentation and support. One of the biggest traps developers fall into is believing that new and trending tools are the best! By nature, it seems developers are early adopters of tech, so it makes sense. Yes, new tools are “suppose” to be better than older tools, but it’s crucial not to overlook the need for strong documentation and community support. The documentation has to be very detailed and must address all components on how they work, integrate with other components, along with best practices. When documentation fails, community support should be the next place for help. If you see a lack of information or poor support (Red Flag!), then chances are you may have to get a specialist for your project or what you want to achieve is not possible. This applies to libraries and packages (core and 3rd party).

Lifetime support is ongoing and consistent. It doesn’t make sense to use SDKs, run time environments that are no longer being supported in the near future, right?

TL;DR;

Know exactly what you want to achieve for your project:
- Establish timelines and budgets before development begins.
- Main successful workflow established.
- Corrective workflows should something go wrong.
Development and Maintenance:
- Keep costs within budget.
- Be able to debug and reproduce bugs, especially ones found in production.
- Make sure the tech stack is safe against OWASP Top Ten vulnerabilities & can deliver according to deadlines.
- Strong documentation and support exist.

This best solution is not black and white, there will be some gray areas, but the best we can do is to minimize this area by looking at different trade-offs.

Why I (And You) Should’nt Just Use Any [Popular] Library

Shannon W — Sat, 28 Dec 2019 15:56:04 +0000

Yes – even if it was made or supported by Google, Microsoft, or Facebook. I know I’m not the only one who encounters situations where you’re excited about working with a new tool, but it turns out it becomes an obstacle.

The main reasons for this are just from logical reasoning, and my experience exploring different libraries for small projects:

Security flaws
- This is my main concern with working with anything open source. To be quite frank, the majority of my encounters with security vulnerabilities have been with npm modules.
Library or Module Support
- It’s open source. Unless the maintainers are VERY passionate about keeping it up to date, continuous with 1-4 week periodic updates, good documentation, issue support, or they’re getting paid (mostly the latter), then chances are it’s going to be short-lived or you’ll mostly be on your own to fix any issues.
Poor Programming/Implementation
- Modules/Tools/Libraries may get the job done, but the way it has been implemented is something every programmer should be aware of. Otherwise, realistically, how do we know the implications using a module will have on the project (good or bad)? Whether it’s in regards to performance, security, or usability.

Honestly, I developed this realization mindset in my last semester at University. What is more interesting, is how my mindset developed since my decision to pursue software development as a career.

(2013) First Year of College – Second Semester – Programming 1 (Java)

Fell in love at first ‘Hello World!’. Afterward, I wanted to quickly develop my skills to get a job locally here in Cayman (Quite frankly, there’s little to no entry-level positions here for software developers). So I began searching the web for java development jobs and used the required Java-related technologies and skills advertised to guide what I’d learn next.

I swore on my pride as a young programmer that Java was life and no other languages were better (oh how that changed right after Programming 2 – C++).

(2018) Last Year of College – Last Semester – Course Projects & 2 Internships Later

Having gained more experience and confidence in my work, I had a slight preference for programming tools. I loved the concept of having open-source frameworks and even ecosystems! Having the flexibility to accomplish anything, and keeping a low budget sounds wonderful to me. However, my over-thinking self couldn’t help but doubt how secure, performant, and easy (or difficult) to work with the tools would be.

At this time, I was more knowledgeable to look at the source code, README.md files, documentation, etc., to learn more about these tools. Yet, still, a bit overwhelmed by the amount of content to learn, sometimes I just couldn’t even bother! I just wanted to get the products built and functional, regardless of how it was done.

(January 2019 – Now) Working as a Full-Time Junior Software Developer – Walkers

Having to work full time, and messing with various small projects, I’ve had nothing but constant failure after failure trying to work with open source tools claiming to be ‘easy to use’, and to ‘take care of the mundane yet mandatory functionality’ within code. Some failures were due to lack of product support, poor documentation, or inability (or in some cases very difficult) to integrate with the current stack to satisfy requirements. Talk about stress! Even some of these tools were made or supported by the big tech companies like Facebook, Microsoft, and Google. Maybe it was me just not doing proper background checks in incorporating certain tools? Either way, my whole mindset of using tools has changed to what it is now.

TL;DR

I didn’t know much about programming concepts and different development ecosystems as I do now. It was not until I had some experience working with various technologies like Reactjs React-Native, ASP.NET, WebApi (.NET Core), Vuejs, NativeScript, etc. and working from small to medium/large projects with a team, that I realized how hyped up a lot of things are! What I can say, is that before incorporating any new tool/module/library, I usually test the tool in a sandbox environment or a small application to see its pros and cons before using in a big project (as should you also). Yes, this is going to require more work and diligence, but it’ll be worth it in the end. Personally, I’ve made a personal promise to ensure my clients get the best service or product from me, so making this extra effort is an obligation by default.

Want to add in a few additional thoughts to this? Then leave a comment below! I’d love to hear your thoughts on this!