DEV Community: Luke Frauhiger

The Form Builder for Developers

Luke Frauhiger — Fri, 01 Apr 2022 16:23:17 +0000

The form building gap
Fetch Forms intro
The form building process
Code examples
- Javascript & html
- React example
- React w/custom components

The problem with current developer form tools

There are lots of form builders and form tools available today. Whether you need to share a simple form with family members, build a complex registration form, or gather payment information, there is a form builder or tool for you. Or is there...I see a gap.

Form backend services help JAMstack websites collect form submissions without a server and connect data to 3rd party systems. But you still have to hand build the HTML form and its supporting functions like client-side validation. On top of that, if you want to use the form submissions locally in your code, as well as use a backend service, you can’t!

Code libraries like Formik and Angular Forms are incredibly helpful for managing form state and validation. You can use your own components and build a high-quality form much quicker than with standard HTML. Unfortunately, you still have to spend time hand-building every single form and its validation rules. You also have to spend time creating a backend to handle form submissions and integrate the data.

Forms are too repetitive and time consuming for developers to constantly be hand-building them.

Fetch Forms

fetchforms.io
That’s why I built Fetch Forms. I wanted the benefits of a form backend service and to be able to build the forms in a form builder that would remove the repetitive aspects.

The Fetch form builder’s defaults and templates will help you build and collaborate on forms in record time.

The Fetch API will help you integrate high-quality forms with client-side validation into your application in a matter of minutes.

Updates are just as easy. Complete your changes and publish them with a single click. All applications using the updated Fetch form will begin to pull the new form.

Get started with Fetch Forms

Get the speed of a form builder with the control of code. Here’s how:

1. Build

Use the Fetch form builder to create and build your form. It’s packed with templates and defaults to make building forms painless.

Select validation rules and input masking
Choose whether to save submissions to Fetch Forms
Use form and field templates to build forms in record time

2. Deploy

Deploy your form using any of our NPM modules, the embed script, or by simply using the native fetch API. The possibilities are endless!

Install and use the Javascript or React library
Use the embed script to drop a form into any web-based tool
Extend your own component library

3. Submissions

You don’t have to send submissions to Fetch Forms — all data submitted is available to your local code no matter what.

If you configured the form to save submissions to the Fetch Forms library, they will be validated on the server and sent through spam filtering. Submissions will then activate any connections you have set up.

How about we look at some code?

Using Fetch Forms can be as simple or as complex as you need. The first two examples are using a styled component provided by Fetch Forms. You can also implement a Fetch form with your own component library - see example 3.

You watch me talk through building and deploying a form in the walkthrough here.

Simple Javascript & HTML example

See more at www.fetchforms.io/docs/fetch-forms-javascript

<!DOCTYPE html>
<html>
  <main style="max-width: 600px; margin: auto">
    <h1>Fetch Forms Javascript</h1>
    <hr />
    <h2 id="form_name" style="margin-bottom: 25px"></h2>
    <div id="fetch_form"></div>
    <pre id="result"></pre>
  </main>
  <script>
    import { renderForm } from "@fetchforms/core";

    // Called when data is submitted
    const onComplete = (data) => {
      document.getElementById("result").innerHTML = JSON.stringify(data, null, 2);
    };

    // Called when the Fetch form is loaded from the API
    const onLoad = (data) => {
      // Set the form name on the HTML 
      document.getElementById("form_name").innerHTML = data.name;
    };

    // Pass in the form slug, element Id to attach the form to, and optional utility functions
    renderForm(
      "__form_slug__",
      "fetch_form",
      onComplete,
      onLoad
    );

  </script>
</html>

Simple React example

See more at www.fetchforms.io/docs/fetch-forms-react

import React, { useState } from "react";
import { FetchForm } from "@fetchforms/react";

const ManagedForm = () => {
  const [formSubmission, setFormSubmission] = useState(null);
  const [formName, setFormName] = useState("");
  const onSubmit = async (values) => {
    /* To show an error on the form, uncomment the line below */
    // return 'There was an error submitting the form.';
    setFormSubmission(values);
  };

  const onLoad = async (values) => {
    setFormName(values.name);
  };

  return (
    <div className="">
      <div className="text-3xl mb-2">Component Form</div>
      <p className="text-gray-600">
        The easiest way to use Fetch Forms. Pass in a form slug and we'll handle
        client-side validation, input formatting, submissions, and styling.
      </p>
      <br />
      <div>
        <h2 className="text-2xl">{formName}</h2>
        <FetchForm slug={__form_slug__} onSubmit={onSubmit} onLoad={onLoad} />
        <br />
        {formSubmission && <pre>{JSON.stringify(formSubmission, null, 2)}</pre>}
      </div>
    </div>
  );
};

With custom components example

This example is using Ant Design as the component library.

See a full working example at www.fetchforms.io/docs/fetch-forms-react

import React, { useState } from "react";
import "antd/dist/antd.css";
import { useFetchForms } from "@fetchforms/react";
import { Form, Input, Button, Checkbox, Select, Radio, InputNumber, Alert } from "antd";

const CustomFetchForm = () => {
  const [fetchForm, loading, error, doCloudSubmit] = useFetchForms("__form_slug__");

  // Called when submission passes client-side validation
  const onFinish = async (values) => {
    if (fetchForm.cloudSave) {
      console.log("Saving to the Fetch Form's cloud");
      try {
        const isSaved = await doCloudSubmit(fetchForm.id, values);
        if (!isSaved) {
          throw new Error("There was an error submitting your form.");
        }
      } catch (err) {
        console.error(err);
      }
    }
  };

  const onFinishFailed = (errorInfo) => {
    console.log("Failed:", errorInfo);
  };

  // This takes the validation rules from the Fetch form and formats them for 
  // the Ant Design form component.
  const createValidationRules = (fieldType, validations) => {
    const rules = validations.map((validation) => {
      if (validation.rule === "required") {
        return { required: true, message: validation.message };
      } else if (validation.rule === "regex") {
        return {
          pattern: new RegExp(validation.limit),
          message: validation.message
        };
      } else {
        return {
          [validation.rule]: validation.limit,
          message: validation.message,
          type: fieldType === "number" ? "number" : "string"
        };
      }
    });
    return rules;
  };

  // Builds out the field based on it's configuration
  const dynamicField = (item) => {
    switch (item.fieldType) {
      case "select":
        const { Option } = Select;
        return (
          <Select key={item.name}>
            <Option value=""></Option>
            {item.options.map((option) => (
              <Option value={option.value} key={option.value}>
                {option.label}
              </Option>
            ))}
          </Select>
        );
      case "checkbox":
        return <Checkbox key={item.name} />;
      case "textarea":
        const { TextArea } = Input;
        return <TextArea key={item.name} />;
      case "number":
        return <InputNumber key={item.name} />;
      case "radio":
        return (
          <Radio.Group>
            {item.options.map((opt) => (
              <Radio value={opt.value} key={opt.value}>
                {opt.label}
              </Radio>
            ))}
          </Radio.Group>
        );
      default:
        return <Input {...item.fieldHtml} key={item.name} />;
    }
  };

  return (
    <div className="">
      {loading ? (
        <div>Loading...</div>
      ) : (
        fetchForm && (
          <Form
            name="HookForm"
            labelCol={{ span: 6 }}
            wrapperCol={{ span: 18 }}
            onFinish={onFinish}
            onFinishFailed={onFinishFailed}
            autoComplete="off"
            noValidate
          >
            {fetchForm.formItems.map((item, i) => (
              <Form.Item
                key={i}
                label={item.label}
                name={item.name}
                valuePropName={
                  item.fieldType === "checkbox" ? "checked" : "value"
                }
                rules={createValidationRules(item.fieldType, item.validation)}
                validateTrigger="onBlur"
              >
                {dynamicField(item)}
              </Form.Item>
            ))}
            <Form.Item
              wrapperCol={{
                span: 8,
                offset: 6
              }}
            >
              <Button type="primary" htmlType="submit">
                {fetchForm.submitText}
              </Button>
            </Form.Item>
          </Form>
        )
      )}
    </div>
  );
};

Fetch Forms is a headless form builder that exists to help developers build and manage forms easily so they can focus on more important things. It’s perfect for headless websites, JAMstack websites, and web apps.

Website: www.fetchforms.io
Docs: www.fetchforms.io/docs
Twitter: www.twitter.com/FetchForms

What are webhooks and how to get started?

Luke Frauhiger — Mon, 04 Oct 2021 17:21:35 +0000

Let’s start off by getting straight to the point: Webhooks are a way for one system to send updates to one or many other systems.

That’s it! That’s all they are.

Have you ever made an API call? Webhooks are very similar, but instead of making a call to an API endpoint, a webhook calls one of you’re endpoints.

How about a real-world situation: You’re using a payment provider, let’s say, Stripe, to manage your subscriptions in a SaaS platform. The recurring monthly charges happen behind the scenes, but you need to record the data about each subscription in your CRM.

To achieve this you can create a webhook in Stripe that will fire every time a subscription is paid. This webhook calls an API endpoint in your system — from there you can add the data to your database!

Webhooks vs APIs

“What’s the difference between a webhook and an API?”, you might ask.

This comes down to who is “calling” who. When you make an API call, you are calling a system and asking for data. However, a webhook calls you and throws the data at you.

I use the term “throw” because webhooks don’t want to wait until your code is done processing before they are given a successful or failed return status.

Using the above example with Stripe subscriptions, to get data each time a subscription is paid you have to create a webhook in Stripe and an endpoint in your system.

To get the same data with an API call you’d have to write code to constantly poll Stripe. Since you are constantly polling you’ll have to manage the polling code as well as the other functional code.

At the end of the day, both solutions work! But the event-driven nature of webhooks makes receiving and working with data much easier.

The right and wrong time to use webhooks

No matter how great a tool is, it might not be the right choice for every situation. Webhooks are no exception - they can be a helpful tool, but if used in the wrong situation, they can become a hindrance.

When to use webhooks

My personal opinion: if you can use webhooks, do it! Not all systems can send or receive webhooks, though.

Webhooks are great for working with time dependent data or apps where you’d have to constantly poll to get data.

Webhooks have lots of indirect positive implications as well. For example — the less code a developer has to write, test, and maintain, the faster they can ship features. Webhooks can help you remove boilerplate code, cron jobs, and some duplication-checking, allowing you to complete features faster.

When to not use webhook

On occasion, processing data can take a long time. If that’s the case, a webhook may not be the answer. Webhooks generally need a quick response based on if the data was received or not. Long-running processes can cause webhooks to time out if they wait too long. The sending platform should have guidelines on what is “too long” for a webhook to wait.

Webhooks may also not be the answer if the system you are sending data to has strict API limits. As an example, Salesforce has strict limits on calling its API. Using webhooks that push data into Salesforce could cause you to unknowingly break these limits and have to wait until they reset.

If you are trying to integrate a webhook with Salesforce, using a tool like Quick Freeze will be a good call. It’ll allow you to batch the webhooks and use a single API call from within Salesforce to get the data so you stay well within your org’s API limits.

Get started with webhooks

To get started with a webhook you’ll need two things.

A system that has the ability to send webhooks
An API endpoint in a system you control

Once you’ve got the sending system setup to send the data to your endpoint, you’re good to go! No cron jobs, polling functions, or deduplication checks.

Local development with webhooks

One of the challenges with webhooks is being able to use them while developing locally. Most platforms won’t allow you to send webhooks to non-secure URLs or localhost. Luckily there are quite a few tools out there to help with this.

Three of the best webhook tools:

Ngrok — ngrok creates a public URL that forwards traffic to your localhost. This is a great option to use when developing locally because it allows you to test your webhook endpoints like they’ll be used in production
Quick Freeze — Quick Freeze can act as a bridge between the sending system and the receiving system. If the receiving system has API limits, doesn’t have an inbound API, or can’t be accessed by external systems, Quick Feeze can catch and hold data until it’s ready to be moved out.
RequestBin — Request bin allows you to receive API calls and webhooks events from a generated URL, similar to ngrok. You can also view the data, integrate with other apps/platforms, and execute steps on the data.

Why My Tech Startup is Failing

Luke Frauhiger — Wed, 26 Aug 2020 13:45:42 +0000

Spoiler - it’s not COVID.

If I knew exactly why my startup was failing, then it would not be failing...Right?

But one thing is without a doubt; my failure so far is not COVID’s fault. Believe it or not, this startup actually came to fruition because of COVID. Granted, starting a business during a pandemic might not be advisable, but my business is failing for one reason alone – me.

Now, before you start to feel sorry for me, let me share a bit about myself.

I subscribe to a worldview of radical responsibility. In the book, The 10X Rule, Grant Cardone put it like this,

“Nothing happens to you; it happens because of you.”

I think this statement is a window into each of our worldviews. Each of us has the ability to add value and goodness to those around us through our relationships. Playing the victim and constantly blaming something else for our failings isn’t helpful to anyone.

Jocko Willink calls this “Extreme Ownership” – and wrote a book about it. Simon Sinek even talks about it in his book, Start with Why, when he says,

“Leadership requires two things: a vision of the world that does not yet exist and the ability to communicate it.”

What is your vision of the world? I see a world that isn’t continually ravaged by COVID-19. That’s not to say that I hope it quickly fades into history – actually quite the opposite. I hope that we grow and unite and become the types of people that can thrive through any adversity. Most importantly, I know that I have a part in that change by taking responsibility for all of my actions – failures and successes alike.

Before you read any further

This is one of my attempts at communicating my vision of the world with you. So far, my attempts at building a business have gone pretty poorly, but I’ll happily take full responsibility for all the failures.

This is not a sob story or an analytical breakdown of all the business and marketing principles I broke. More than anything else, this is an amusing tale of my first attempt at starting a business. I’m masking the name of the business, and I’m not going into detail about my team to add a layer of privacy for us all.

I sincerely hope this inspires you to spread your vision of a better world! I’m learning that failure is ok – it happens to everyone. Quitting, on the other hand, is something else entirely.

How my failure started

Everyone's life has been a whirlwind since COVID-19 dug its claws into the world. Like a lot of people, I lost my job early on in the pandemic. I had been a software and web developer for the previous seven years, so I figured it would be easy to jump into the freelance world. After all, the entire world was going online – so how hard could it be?

Hard...it was very hard. You’ll notice my blind optimism will be a common trend.

I struggled to quickly learn all of the auxiliary skills that it takes to be a freelancer. The truth is that I didn't really want to learn them. I didn't want to be a freelancer and work by myself all the time. I wanted to lead and develop a team and start my own business.

Books fueled the fire

A couple of years ago, I resolved that I wanted to be more active in self-growth, so I started reading. I hated reading in high school and college, but I've come to love the ability to reach into people's minds and learn from their experiences. I quickly found my favorite type of book: “straight-talk” about leadership and business.

I've always been a little taken by the topic of leadership. Maybe because I've encountered so many poor leaders in my life and that makes me want to be an amazing one. Maybe because there is no right way to be a great leader. Maybe because I enjoy power and prefer to be in the driver's seat most of the time.

These books opened my eyes to a world that was so much bigger than the one in which I lived. It was a world of radical responsibility, business ownership, discipline, and continual learning. But the intelligent and passionate minds I was reading didn't have it all figured out. They had been tested by fire and struggled just like the rest of us mortals. The more I read, the more humanized these individuals became, and I began to realize that I could learn from their stories and forge my own path.

Success was going to be easy

The idea of being a self-made man and a great leader is intoxicating to me! So when I was let go from my job of seven years, I knew I wanted to become an entrepreneur and start my own business. I wanted to test out all of the things I had read about and learned over the past couple of years.

The word “entrepreneur” is a super-buzz-word right now. It seems like everyone wants to be an entrepreneur, and the one million people selling courses on (use your infomercial voice) "How to make $1 million dollars with THIS SIMPLE HACK" seem to be making it easier than ever. I figured with my driven nature, desire to hustle hard, and book knowledge, it would only take a great idea before I was a success.

I found the million dollar idea!

Not too long into my freelancing career, in which I had booked zero gigs, an old friend asked if I could build a web app for his non-profit organization. They wanted to have in-person events and needed a tool that would help them socially distance their seating and limit their capacity. I thought it was an incredible idea! During our second meeting, I negotiated owning the intellectual property (IP) to help other non-profit organizations with the idea. He was happy to relinquish the IP, and I was off to change the world!

His organization, however, was not thrilled with the amount of money I was requesting to build the application. Even with a heavily discounted price, almost 50% and free lifetime use, the organization said no; they opted to wait until I had built the program on my own. Needless to say, that was not the outcome I had hoped for, but I was excited to have a seemingly great idea to work with.

In hindsight, this was a sign of the struggle to come. Even the originator of the idea didn’t believe in it enough to invest. They quickly found a cheaper solution that seemed to solve the problem.

But I was convinced that if I could build this web application and provide it as a subscription service, my friend’s organization and hundreds – maybe even thousands – of other non-profits would love it and, most importantly, subscribe to it. It didn’t take long before I completed all of the legal documents and signed the forms that legitimized my new business.

I began to rapidly flesh out the idea. My experience in full stack web development was paying off. I was able to plan out the database architecture, design high fidelity mockups, and code the entire thing. Very quickly, however, I realized that there was too much work for one person to do. I had to bring someone else onboard.

At least I got that part right!

Avengers, assemble!

With the realization that I couldn’t do everything by myself, I started looking for people to bring on and help me. Luckily, I had a good friend who had been working at the same non-profit as I, pre-COVID. He was let go from his job, as well, and I knew he would have his interest piqued at the prospect of this new adventure.

Let me preface something before you read further. I know the startup lifecycle as well as anyone. I know that market research and validation are foundational to starting an online business. And it makes 100% sense, right? If the market you are trying to sell to doesn't have the particular problem you are trying to solve, then you don't have a business. Somehow I seemed to have forgotten this...

My friend was a talented salesman and had been working with non-profit organizations for the past several years. He had deep connections, and we were both absolutely convinced that we could bring the service to hundreds of organizations easily. He signed on as my Co-Founder, and we were off the races.

Literally... races. We both agreed that this service needed to be done yesterday. I rallied a few other developers I knew had been let go from their jobs because of COVID and I temporarily brought them onboard with my vision. Our goal was to build, test, and launch two web apps required for our service within four weeks.

Feature Creep

Being in software development for a while, I knew that feature creep was a problem that we’d run into and a huge threat to launching on time.
If you don’t know what it is, feature creep is the act of adding additional functionality to a feature or product during its development that detrimentally pushes back its release. The continual addition of new things to the project makes it very difficult to find a stopping point and can easily kill a project by never allowing it to be “done”.

I wasn’t about to let Feature Creep get its hands on my project. I fought hard to keep our launch date realistic and only let in features that were required for our MLP - Minimum Lovable Product. Aka - the smallest and least feature rich product that will still have value for the customer.

Did you notice my HUGE misstep? This is probably the single biggest reason for its failing so far. No market research or due diligence, of any kind, was done. We jumped into building and marketing so quickly that we forgot to see if the market was interested in this type of solution. I didn’t realize it then, but we were flying blind. This is made even more evident when we get to pricing the service. Stay tuned.

I rarely shy away from a bit of hard work so I relished the idea of working really hard to start my business. It seemed like a rite of passage based on the stories I had read. Plus, my team and I loved building the web apps – the sense of urgency was a welcomed change from quarantine and unemployment.

It’s alive!

Six weeks later and around 500 hours of work from myself alone, and the service was built and stable. I was so proud – and so almost-kinda-sort-of-burnt-out.

“Can we stop talking about money?”

Over the entirety of development, my co-founder and I had gone back and forth on how much to charge for the service. We had changed the pricing several times and even had transitioned from a flat monthly fee to a pay-per-use model. The pay-per-use model was super confusing and required an explanation from one of us to be understood. Nonetheless, it was a great offering for scaling and made sure we covered our baseline costs.

Pricing was so hard for us to nail down because we had no idea how valuable our solution was. Since we hadn’t done any research, we had no idea how customers were viewing this problem and how much they would pay for a solution. We didn’t even know if our type of solution would be desired by our customers! We were basing the price purely on how amazing we thought our solution was.

Once the service was stable and we figured out the pricing, we decided to launch! Why hadn’t we “launched” long before that, you ask? Well, we had to make sure we were 100% ready because customers were going to sign up in droves. We were absolutely certain of it.

I don’t know why I thought we had to have a completed product before we could start marketing and getting leads. Marketing and sales can be rather difficult and they take time. It was a bit insane to think that we were going to have loads of sign-ups with no marketing and only a dozen 1-on-1 meetings with potential customers. So the tale continues...

Launch Day!

We launched on a Tuesday with a barebones website, no active marketing of any kind, and no budget to scale with. Surprise, surprise – nothing happened.

My co-founder and I kept working really hard, almost doubling our efforts. He kept reaching out directly to customers and scheduling demos, and I was implementing group marketing while also continuing to build and improve the service.

Unfortunately, sales were still going nowhere. Even with a talented salesman and a deep network, we couldn’t get traction.

GET THIS – even before launching, we had leads! Quite a few of them, actually. But none of them took the plunge and signed up. Business 101 – understand your market! We actually had a great service that our customers thought would be helpful, but the onboarding was a little too difficult and the price tag gave them sticker shock.

Being a web developer, my first priority was the marketing website. It wasn’t a great sales funnel, and I figured that redesigning it would help bring in numerous more sales.

Once again, I put my head down and worked hard to build a stunning website that would drive traffic to demo requests and make sales. But upon completion – nothing happened. Turns out, you need traffic to your website to make sales on your website.

How to get traffic when you are not a marketer

I’ve built websites and sales funnels before. I knew good practices for conversions, and I even knew a bit about Facebook ads. But I would not call myself a marketer, by any means. I was hesitant to lean into marketing and sales because I didn't want to step on my co-founder’s toes. He was good at sales and, most importantly, he was my entire outbound marketing strategy.

Have you heard the saying “Don’t put all of your eggs in one basket?” It exemplifies this situation and how I treated outbound marketing. Our Plan A was to make initial sales through my co-founder’s non-profit network. We both thought it would be easy with his relationships and history. But we quickly found out that it was not going to be easy! Our plan B was… there was no plan B.

I think I’m learning!

I wised up a bit and began doing market research by reaching out to influencers, Facebook groups, Reddit threads, and online magazines. I wasn’t even looking to sell; I was hoping that talking to people about the service would simply generate traffic and that that traffic would generate customers.

What I found through my research was a massive gamut of opinions on COVID-19 and the tools being used to solve social distancing and capacity limits for live events. I can’t go into details about the market, but the diversity of opinions illuminated a lot about why we had been struggling to get traction.

At this point I began to realize a few things. 1) We were very overpriced, 2) we needed more features to be attractive and 3) We needed to find more effective verbiage so we could showcase our value more effectively.

Talking directly to people in the market wasn’t very helpful, initially. Each organization was looking for something different, and most that wanted to hold live events had figured out a solution already. This left very little room for a premium-priced service.

To combat one of those problems, we changed our pricing from the confusing pay-per-use model to a monthly, flat fee and dropped the price by almost 50%. Our service was now slightly lower but appropriately priced against its competitors – a change that would undeniably make the service more attractive and bring in sales.

Can you guess what I’m about to say? Unfortunately, the change did not boost sales. We had a few more leads, but no one was converted into a customer. We still weren’t able to get any traction.

The beginning of failure

I’m a strategist at heart, but for whatever reason, I wasn’t able to see that I didn’t have any kind of plan. I was being purely reactive – changing things week to week or day to day because nothing was working. I never took the time to get the altitude I needed to make long-term and thought-out decisions.

All of those eggs in one basket

At this point, it had been around two and a half months since launch day, and my co-founder told me he had some bad news to share. He had to pick up another job to keep his house. That means he has very little time to work on our business. It took courage to have that hard conversation with me, but his decision was completely understandable. Life during COVID-19 is hard and ever-changing and it often requires hard sacrifices. Nonetheless, I all but lost my teammate when he cut his hours back.

One of the things I’m proud of is the way I handled that situation. I would never have asked or expected him to sacrifice his home for our business. I wanted our business to be successful more than I wanted most things, but people will always be more important than business or money in my book. I was disappointed when he stepped back, but I recognized the hard situation he was in and didn’t hold his decision against him.

Putting more pressure on me, the developer I had on contract was very close to getting a full-time gig. His contract was written so that he was paid based on how much money the business had made and at this point, we had made $0. He had rent and groceries to pay for, just like the rest of us! When he was hired for his new full-time job, he stepped back and cut his hours down to under 10 per week.

That week ended with zero sales and with the entire weight of a failing business on my shoulders.

I know I said this isn’t a sob story, but that is pretty sad, huh? But that’s as low as it goes. The only direction to go is up!

Who's to blame?

It would be easy to blame this failure on COVID or even on my teammates. After all, they did choose other priorities over our business. But I think there’s much more in their decisions than meets the eye.

They cut back hours and choose other priorities because I was unable to lead them in a successful launch or post-launch sales campaign. Jocko Willink’s words in Extreme Ownership are ringing true in my ears:

“There are no bad teams, only bad leaders.”

“I’m going on an adventure!”

It doesn’t end there, Bilbo Baggins. We’re now several months post-launch (at the time of writing), and we are still going. My co-founder is working really hard and making time for our business, which has breathed new life back into me and the business. If nothing else, all his hard work is an incredible blessing to me.

And me? I’ve been taking some time and learning from my mistakes - hence this article. It hasn’t been easy, but I’m doing my best to be patient and develop a great strategy for scaling up and gaining traction.

Also - we have customers and demo requests coming in - it’s slow, but we’re trending upwards! Maybe time will turn out to be the secret sauce to it after all.

Failure isn’t always bad

Here’s the short of it - failing isn’t objectively bad. It’s hard and can feel terrible when you’re in it, but it is the best teacher. I don’t think you are a “failure” when you make mistakes and “fail”. I think what makes you a true failure is when you give up.

Because of that, I’m not giving up. I have an abundance of things to learn and it would be wrong for me to quit now. I’ve failed to launch this business well, but there is life left in it! I think the idea behind this service is incredibly helpful and I think that the longer COVID sticks around, the more organizations will realize they need a solid, long-term solution.

I’ve made a lot of mistakes to get myself here. Ironically, I feel more prepared to take on any future businesses now that I have taken time to slow down, and can clearly see where I’ve failed in the past.

At the end of the day

I did something that most never will – I started. I’ve had a hell of a go so far on this business and I’m sure it'll be laborious going forward but I’ll pay that price to bring value and safety to non-profit organizations.

At the heart of this is my desire to better the world around me; to add value to people’s lives so they have more energy and life to give to others. That’s my mission and it’s worth a lot of hard work and sacrifice.

Get started with full-stack development - Svelte and Express

Luke Frauhiger — Tue, 11 Aug 2020 17:52:11 +0000

Full Stack Development Starter - Svelte and Express

Svelte and Node.js

Knowing how to build either a frontend or backend is a valuable skill. I started my career in technology as a UI/UX designer, but I hated that I couldn't help turn my designs into a functional app. That's when I jumped into frontend development! I desperately wanted to do more than design the interactions - I wanted to be able to build them!

Learning frontend design was a great challenge and it was amazing how much it affected my designs. Knowing more about data structures, data manipulation, and the capabilities of various frameworks forced me to think critically about the designs I was doing. It especially helped with the hand-off between myself and developers. Terms like, "I don't know how to do it, just do it", left my vocabulary and I was much more helpful in the implementation. Something my fellow developers are thankful for to this day.

However, for most people learning just frontend or just backend isn't enough. To put a website or web app on the internet for all to see, you have to know more than just one discipline. That's why I'm writing this! I hope this article helps you with your journey of building and deploying a Svelte app. There are other ways to deploy Svelte and the other SPA frameworks, but using an application server is one of my favorites if you need to do backend & API work.

Before we begin

Before we jump in let's go over some details.

You'll need Node.js installed - you can download it here if you haven't already.

You can access my template repo with the completed files here.

The plan

The plan is to create a Svelte frontend, a Node & Express backend, and wire them together so that our frontend can search for gifs from the GIPHY API. This will be a great example of why using an application server can be so great for your full-stack development. It keeps all the files in one place and sensitive data, like API keys, are hidden in the server and not your frontend.

So...Svelte is awesome, right?

As a full-stack developer of 7 years, I honestly say that Svelte is pretty amazing...but not for everything. Here is a saying that I've said far too often in my career

"Anything can be used as a hammer"

I'm a huge advocate for using the right tool for the job. Sometimes that means it's going to be Svelte, sometimes it won't. You could choose to use Svelte for all your projects and that might be a great call for you. It might not be a good call for someone else.

My personal opinion - I wouldn't use Svelte for bigger applications. It's not because Svelte can't handle bigger projects! It's because I think tools like React or Angular provide much better tooling and organizational potential than Svelte does. For our small example today, I think Svelte is perfect!

Let’s jump in

The first thing we’ll do is create our Svelte app. To do that, we’ll follow the instructions on this page and run the following:

$ npx degit sveltejs/template svelte-express-app

If you haven’t used npx before, it’s an executable package, baked into NPM, that enables one-time use of an npm package. In this case, npx is executing the tool degit to pull down and clone the Svelte template repo. You can read more info about the degit project here.

This command clones the Svelte template repo and names it “svelte-express-app”. Once the command completes, install the project, and you’re ready to begin developing with Svelte! Let’s run the following commands to get our Svelte app 100% ready.

$ cd svelte-express-app
$ yarn
$ yarn dev

We can now begin to develop our Svelte app! Let's move to the Node.js backend.

We’ll use Express on top of Node.js to make building the API super easy. To get this started, we'll first install Express and CORS.

$ yarn add express --save
$ yarn add cors --save

Now that we have Express added to our project, let's create the server file and get it set up so that it can serve the Svelte app. It's important that the server file is outside of the "src" folder. Since the Svelte app is within the "src" folder, everything within it gets compiled and bundled through Rollup - the bundler that Svelte uses. Since we want our server to be separate and serve the frontend to the browser, we need to make sure that the server file is outside of any directory that's being compiled.

NOTE: You could write Node.js and Express with Typescript and need it to be compiled. But that's a slightly different process and one we're not going over in this article. If that's something you'd like to see, let me know!

Let's create our file at the root of our project. I'm going to name my file "server" - I'm really creative, I know! You can create the file with the following command or however you're favorite editor allows you to.

$ touch server.js

Open that file up and add the boilerplate code for Express

const express = require('express');
const app = express();
const port = process.env.PORT || 5000;
const cors = require('cors');
const path = require('path');

app.use(cors());

These lines of boilerplate do several things. They set up the express app, assign a port if the application doesn't have one, import the CORS and Path libraries from npm, and finally, it assigns the Express app to use CORS instead of the baked in security. Cors is really helpful in fine-tuning the security of your application in regards to what domains, outside of your hosting domain, can be used to access the server.

Just a few more lines before we're ready to use the server!

app.use(express.static('public'));
app.get('*', (req, res) => {
    res.sendFile(path.resolve(__dirname, 'public', 'index.html'));
});
app.listen(port, () => {
    console.log(`Server is up at port ${port}`);
});

The first two functions are used to serve the index.html in the public directory to the browser. If you'd like to read more on how the Path library works take a look here, but It's essentially a baked in library that allows Node.js to read and write files!

The last function is a listener that prints out a statement about the port number of the server! This is a really quick way to know if the server is up when developing locally.

Let's Test

Let's test each app separately to make sure they're working. Make sure you kill the process before you run another one.

yarn dev to start the Svelte app. Go to your browser and check it out!

node server.js to start the express app. The console should read Server is up at port 5000

Starting Both With One Command

Now that we have our frontend and backend configured, we need to spin them up! There are differences in the build process between development and production. To serve this in a production environment, it's a pretty straightforward process.

Build the Svelte app yarn build
Start the server. yarn start

It's so simple because we don't want the Svelte app to be hot reloading. For production, we want a super-performant, minified bundle that will load in the browser quickly.

But for development, hot reloading is a must for the Svelte side of things! We'll have to adjust the package.json scripts so we can re-compile the Svelte every time we make changes. And we need to serve the Svelte app from our Express server instead of Svelte's default serve library.

Svelte uses the library "sirv" to deliver the compiled bundle of Javascript to your browser. Let's open the package.json file and take a look at the "scripts" part of the file. You'll find a "start" command that uses the sirv library to serve the public folder. Let's change that FROM "sirv public" TO "node server.js". This creates a single command that will hot-reload the Svelte app and use our Express app as the server. Let's give it a go!

yarn dev

Go to your browser at localhost:5000 and see it work! You should also see the console print out the port number.

You're done! But there's more

Congratulations, you've built a full-stack web app that is incredibly easy to develop! But we're not going stop there. Let's add an API endpoint to our Express app and use the GIPHY API to search for gifs.

Adding a route

The first thing we're going to do is add a new route to our Express.

app.get('/giphy', (req, res) => {
     console.log(`Searching for a gif with the term: ${req.query.term}`);
    res.send({
        success: true,
        data: []
    })
});

It's incredibly important to note that this function MUST BE BEFORE the app.use() function that sends the index.html to the frontend. If you place this function after that app.use() function, nothing will happen on your request.

The first line is the Express function that declares the URL path of the endpoint and which HTTP verbs can be used for it. This endpoint can be accessed through localhost:5000/giphy and it's a "GET" function only. You can also use other HTTP verbs like POST, PUT, and DELETE. If you'd like to use an endpoint for everything, the "USE" function is the perfect choice.

The next line is a console log to print out the search term and then we have the res.send() function that sends our data back to the frontend. There's no special sauce here - you can return whatever you'd like from your endpoint. In my experience creating an object that has a success flag and then a property with the data makes it easy to do success/fail conditionals in the front end.

Making the request from Svelte

Now to Svelte! Open up App.svelte and replace the paragraph after "Hello World" with the following:

<div class="search-block">
    <input type="text" placeholder="Search for gif" bind:value={searchTerm} />
    <button on:click={searchForGif}>Search</button>
</div>
<div class="gifs">
    {#if gifs.length > 0}
        <div class="gifs-grid">
            {#each gifs as gif}
                <iframe src={gif.embed_url} title={gif.title} />
            {/each}
        </div>
     {:else}
         No gifs to show yet
     {/if}
</div>

Now, add this javascript in the script tag.

let gifs = [];
let searchTerm = "";

async function searchForGif(e) {
    try {
        const returnValue = await fetch(`/giphy?term=${searchTerm}`);
        const response = await returnValue.json();
        gifs = response.data;
    } catch (error) {
        console.error(error);
    }
}

At this point, I'm assuming you know Svelte and it's flavor of syntax, so I'm not going to talk in detail about how this works. From a high level, the button calls a function that uses the value bound to the input field and calls to our Express endpoint. On return, the code is formatted and assigned to a variable. Once all that code is added, you should be able to type something in the input field, click the button and see the Express server log out the search term. Since we're not returning any data from our endpoint, the Svelte won't change or display anything.

Using the GIPHY API

Let's change that - let's add the GIPHY API. To make API calls from Express, we'll need to add a library. I like axios, but node-fetch is another popular one. Run $ yarn add axios to install axios and then add the require() to the server const axios = require('axios');

Now we're ready to add the API call. In the /giphy endpoint replace the contents with this:

console.log(`Searching for a gif with the term: ${req.query.term}`);

let params = req.query.term.replace(/ /g, '+');
params += '&api_key=YOUR_API_KEY';
params += '&limit=10';

axios.get(`https://api.giphy.com/v1/gifs/search?q=${params}`)
    .then(function (response) {
        res.send({
            success: true,
            data: response.data.data
        })
    })
    .catch(function (error) {
        res.send({
            success: false,
            data: []
        })
    });

The first part of this code takes the term variable and replaces any spaces with a plus sign. The next two lines add the API key and a query limiter. These are all well documented in GIPHY's doc here.

The axios function will make a GET request to the endpoint and then resolve or reject, sending the appropriate response back to the client.

Before you can query the GIPHY API, you'll need to get your own API key. Head over to their developer page and create an account and an app. Make sure you select API when you are generating a key. Then copy and paste that bad boy after the YOUR_API_KEY param in the code above!

Search for Gifs!

Once you've added your API key to the endpoint you're ready to use the search functionality!
Restart your server with yarn dev and type something in the search box and hit the button! A grid of 10 gifs should popup! This project is super extensible, so feel free to hack around and explore it on your own.

You can access my template repo with the [completed files here.]((https://github.com/lukefrogger/full-stack-starter-svelte-express-app)

Options for Deploying Full Stack React App

Luke Frauhiger — Wed, 05 Aug 2020 15:21:47 +0000

One of the greatest things about programming is that there are a huge number of ways to do things. There often is no right or wrong way. I would argue that there is a better and worse way to do things, but that is beside the point. The ability of us, as developers, to create something out of code that can add value to people’s life is second to none!

So. Many. Options

With all the building and deployment options afforded to developers, choosing the right one can become incredibly overwhelming. Ben Schwartz, a well-known psychologist, calls this "choice paralysis". He argues that more choices make us less likely to take action and to be less satisfied with our eventual decision.

With so many options and services in the deployment landscape, it can be quite difficult to narrow them down and make a good choice on what platform, price point, and availability are right for your application. To make matters worse, you might get so caught up in researching the options that you lose all momentum on your project.

That might be where you’re at now, or you might just be starting out and need some direction. Either way, let’s keep you moving forward and get your deployment started. Just one thing before we start...you have to promise me that once you read this article, you’ll choose a platform and deploy. Deal?
Deal!

Keep Moving Forward

Below I’ll share some helpful guidance on how to deploy your React app and a comparison between a few of the most popular platforms and their pros and cons. This isn’t an exhaustive list nor an in-depth how-to guide. But I hope it helps you along your development journey.

With the advent of FaaS or “serverless”, the use of application servers has fallen pretty dramatically. If you aren’t sure what the difference is, let me fill you in. An application server is a server that runs to serve your frontend application (React in our case) and act as middleware. Middleware can be used for a whole host of things, but I tend to use it as a light-weight backend for code that is specifically used in the frontend it’s serving.

Because of the different needs of serverless and application servers, I’m going to make a list for each type.

Deploy an application server

1. Render
My first choice is Render, which is the new kid on the block. They’re a fledgling startup that won the 2019 Startup Battlefield at Disrupt. They provide a host of tools including databases, disks, and web hosting with very little or no vendor lock-in. They are also very straight forward about the resources you are paying for and are incredibly easy to use. Render will only deploy with GitHub or GitLab, but it automatically connects to the repo and will auto-deploy on push!
For use with an application server, their pricing starts at $7 as of the writing of this article.

2. Heroku
My second choice is Heroku. My least favorite thing about Heroku is that it’s super shady about their servers, or as they call them, Dynos. Nobody really knows what a dyno is, but they’re known for not scaling poorly. Bigger apps can slow down on Heroku, even though you’re paying a premium.
Similar to Render, you can use Heroku with no vendor lock-in and auto-deploy from your Github, but not GitLab. Heroku does have a free version, which is great for prototyping or side projects, but their paid tier starts at $7 at the time writing.

3. Back4App
I have Back4App on this list because it’s widely used and I’ve heard lots of good things about it. To get a picture of how it works I created an account and went to deploy one of my projects. Long story short, I stopped before I got it deployed. Back4 is an astonishingly deep tool that is more than capable to handle an entire enterprise stack. But if you’re looking for an easy and simple process to get your app deployed - this isn’t it. Use Render instead :)

Deploy a serverless app

1. Netlify
My go-to option for serverless or static site deployments is Netlify. Their free tier is awesome! The platform has an astonishingly large amount of features and they've all been easy to use - something I cannot say about all platforms in this list(Back4App). For example, you can integrate a form in your project with Netlify’s form handler giving you the ability to send notifications when a form is submitted and storing them in Netlify for future viewing. All for free! You can also connect Github, GitLab, and BitBucket with subsequent auto-deploys. Easy and free with tons of options - my top choice!

2. Render
The second place goes to Render. It’s easy to use and you can connect Github or GitLab for auto-deploys. They’re the 2019 Startup Battlefield at Disrupt and are taking on giants like AWS and GCP to simplify the developer experience in regards to deployment and hosting. Since Render also can host things like servers and databases, it would make for a great place to host if you’re expanding with an Expressjs API or database. Most things in Render are paid, so if you’d like to spend $0 on your entire full-stack, Firebase might be your jam.

3. Firebase
Firebase is pretty incredible. It’s only last because, as far as hosting goes, you might have to pay for it if your app is used enough. Hosting your frontend on either Render or Netlify can be 100% free, whereas Firebase might charge you. Firebase will charge if the data transferred or hosted is larger than a specific limit. Meaning that you could get charged or your app shut down if you hit that limit.
I actually love Firebase! I use Firestore and Cloud Functions in a lot of my projects, but I’ve never hosted using Firebase because I think there are better options out there. I have a production app that is hosted in Render but uses Firebase for the database and backend. It’s my favorite combination!

Full Stack Considerations

Since your Fullstack application isn’t just the frontend there are few things to consider when deploying. Whether you’re using an application server or going serverless, the needs on your application are the same. You’ll need some kind of API to connect to a backend and database to store your data.

I typically advocate for devs to try managed backends first. Databases like Firebase’s firestore, or AWS Amplify (DynamoDB) can help you move quickly and have to manage less infrastructure. With that in mind below is my top choice for an inexpensive and fast deployment stack.

Here is my top pick for hosting & deployments for your full-stack application.

Render Hosting & Firebase Backend
What's it for: Serverless hosting & managed backend

It’s no secret that I love Render’s hosting and platform. It takes all the great features from bigger competitors like AWS or Google Cloud and simplifies them down so you don’t need an MBA and 7 days to figure them out. Using Firebase’s Firestore and Cloud Functions as the backend provides you a huge amount of flexibility and takes the complexity of managing a database and API off of you.

Using Firebase does lock you in, but if you have a well-designed app, changing over to MongoDB with a streaming library like RXJS, won’t be too terribly painful.

Why I love it

100% frontend hosting
Huge free tier for database and API (Firestore & Cloud Functions)
Backend is managed for you
Get started very quickly

Wrap up

There are all kinds of amazing options there for deploying your full-stack application. When I look for a platform to host and deploy, I focus on ease and simplicity. That’s why I haven’t included some tools like Amplify or GCP in my comparison. They are incredible tools, but they have a steep learning curve and require you to take substantial amounts of time learning them.

I want my deployments and hosting to be quick and easy. After all the work you’ve put into building and testing your app, the last thing you should be doing is learning how to create and manage a VM before you deploy. There is a time and place for VMs and enterprise tooling, but often we just need a simple way to get our ideas and code to the public.

I hope you found this helpful! Now...go forth and deploy!

Analyze My UI: Behance.net

Luke Frauhiger — Fri, 31 Jul 2020 19:30:29 +0000

Analyze My UI is a series where I breakdown the UI design of web apps and mobile apps. We’ll talk about the design and usability priorities, the hierarchy, the colors, and just about anything else that impacts the way that users interact with the application.

UI design is a balance of priorities and it can be difficult to find the proper balance for your application or product. Hopefully, this series helps you define the various priorities and make better decisions in your designs.

Today we’ll be going over Behance.net. The popular portfolio website does some interesting things to put it’s content in the spotlight and not distract from the primary purpose of the application. Let’s jump in.

Cards

Behance uses several different card layouts throughout their site. On the Home page, they already have two different layouts: a categorical filter and their flagship, “project” card.
Home Page

They also have a slightly different project card for the Search and Filter page. The differences make sense - just keep reading!
Search & Filter page

But in both the project cards, you can quickly see what Behance thinks is the most important data for you to see:

The Design
Creators name
The Design's Name (only on the filter page)
Number of likes
Number of views

I think these make sense for a portfolio platform. Since you can’t do much on Behance but look at designs and follow designers, the emphasis on views, likes, and users make sense to me. They try to drive engagement through the few interactions they have on each post.

Let's walk through each one of the above a bit more:

1. Design

The backbone of the platform and the most important content. The rest of the data could be removed and the platform would still have some level of usefulness and relevance.

You might have missed the gravity of that statement. If Behance took away everything on their home page except the images of uploaded designs, their platform would still be useful! All the other stuff on the site is fluff...helpful fluff. But still fluff. It’s a lesson in radical prioritization as Behance has clearly made everything about the projects it hosts. Even it’s branding gives clues to this, but we’ll get to that in a sec.

2. Creators Name

Since it's a social platform, Behance has the creator's name on the card so that people can build a reputation and quickly navigate to other designers’ account pages. This shows us that Behance thinks that it's users, their reputation, and the ability for designers to follow each other is very important. They want people to connect person-to-person not just person-to-design.

Behance is a portfolio site which means there’s not much engagement to be had between users. But they try to drive engagement through the Follow, Save and Appreciate buttons within the design page. It’s completely normal for us to see actions like this nowadays, but I point it out to make you think about where you can add helpful and valuable, micro-engagements in your designs.

3. Design's Name

This one is funky. On the home page, the card doesn’t display the design name. But on the Search and Filter page, it does. What do you think that means?

I don’t work for Behance, so I can’t tell you why they made that decision, but I can tell you what I think. The home page and the Search and Filter page are about two different purposes. The home page is 100% presentation and ease of access. It’s heavily curated for showing the “best of” categories! Sounds like it’s the perfect place to quickly and easily get inspiration and see fellow designers work.

The Search and Filter page is for...well, searching for projects. The curation gives way to a giant search bar and secondary filters. This page needs more data on the card because here users are looking for in-depth content that matches a specific search query.

You might also notice the priority and ease of access to the text search versus secondary filters like "Tools" and "Creative Fields". This, in combination with the “more data” paradigm on the search and filter page, tells us that Behance thinks that users will find it easier to use the text search over other filtering tools.

4. Number of Likes

Similar to Instagram, displaying likes is a way to gamify or psychologize engagement. Based on how users interact with the platform they might want to follow designers with a huge amount of likes or they may search for lesser-known designers and give them likes. Regardless, it's a bit of a measuring stick that Behance thinks it important to drive engagement - probably since it's the only way to interact with a design outside of being able to "follow" another designer.

5. Number of Views

Views are the foundation of most things on the web. If you are particularly cruel to yourself you might compare views to likes and base your worth on the corresponding percentage. Don’t do that - you’re amazing as you are :)

Views are another way of driving engagement on content that is generally non-interactable as well.

Overall Priorities

The cards on Behance do two things. They present the most important data to the users and they show just enough data to entice engagement and curiosity.

I’d like to point out there at there is not “Show More” or “More Details” on the cards. Behance has shown it’s commitment to Hick’s Law by restricting the amount of data you see on the cards. Generally speaking, when in doubt, show less data.

Branding

Behance’s branding is very minimal. Being part of Adobe, even the Create Account and Login pages have creative designs but have very small amounts of standalone branding. This is not on accident, I’m sure.

Everything you do as a designer should have a purpose. Every color, placement, line, and character should have a meaning you can define.

Behance knows that it will be very difficult to have a strongly colored or designed brand while facilitating the curation of other designers’ work. Behance wants it’s branding to fall into the background and be invisible. You can tell this first and foremost by their use of color.
Black
Or Blackish….technically it’s #191919 which is few steps above black.

Their primary use of black in the header and solid white as the body background tells us that they don’t want users to be distracted by their branding. They once again focus their users wholeheartedly on their content.

The only other color I’ve seen them use is a primary-blue which contrasts nicely with the black and has enough contrast to stand out from white.

Branding and You

Branding and color are a hot topic. Every business wants an amazing brand that sets them apart. Something that isn’t readily thought of by most brands is how their brand interacts with their business. If you are a solo freelancer and your brand is your name, then a flashy and highly stylized brand & color guide would great! But for a company like Behance, that wouldn’t work at all.

Behance is a platform that helps designers through curation and promotion. It would be conflicting if they tried to step into center stage and took the focus off of their content.

Finally...

Behance is a pretty simple website. Or at least their superb use of design and navigation make it feel that way. Over and over again Behance has made design decisions that make its visitors focus on the content they host - at the very cost of Behance’s own identity. Imagine trying to explain that your non-designer boss, “I want to remove most of our branding and make our color palette pretty lame, so visitors don’t get distracted by it”.

But designing UIs is all about priorities. What your business deems the most important will be pushed up the hierarchy whether it’s your brand, your content, or your products.

If you’ve enjoyed this post and want to read more, let me know what website or app you’d like me to analyze next!

.ltag__user__id__5745 .follow-action-button { background-color: #0D58A6 !important; color: #FF9900 !important; border-color: #0D58A6 !important; }

Luke Frauhiger

I'm a full-stack developer, a web designer, and a software architect. I'm seeking to help other developers and businesses grow in their knowledge and use of technology.

lukefrogger https://lukefrauhiger.com

Full Stack Development Starter 1 - React and Nodejs

Luke Frauhiger — Mon, 13 Apr 2020 16:13:36 +0000

When I went from being a UI & UX designer to a programmer I had literally no idea what I was doing. What made it worse was that I didn’t have any mentorship or guidance on how to move forward. All of my coworkers were Salesforce developers and hadn’t built any full-stack web apps with industry standard technology. It was up to me to pave the way forward with a new technology stack and deployment strategy.

With no idea of what to even Google and almost no concept of what it takes to build a full-stack application, I headed into the technological wilderness to find my path. After several weeks of research about coding languages and hosting platforms I finally had a full-stack application completed and running on Node.js and Angular 2+.

I often wonder what this project, or even the next couple of years of development, would have looked like if I had mentorship while figuring all of this out. That’s my goal with this article - to act as a simple mentor and get you started down the full stack trail.

Three Part Series

We’re gonna be working with React and using three different server-side languages: Javascript(Node.js), Ruby, and Python. Node, Ruby, and Python are some of the most widely used server-side languages in full-stack development because they’re very easy to spin-up on and are quite fast to develop on. Each of them also has a tightly bound middleware that makes serving HTTP(s) requests incredibly easy. For Node this is Express.js, for Ruby it’s Rails and for Python it’s Django. We’ll get into this more later on. But I’ll stop gabbing now and we can get to the code!

React and Node.js

We’re gonna start with a full javascript stack. This can make developing and deploying full-stack applications a breeze since you only need to know one language.

Note: I’m primarily a javascript developer but it’s beneficial to learn a scripting language like Python or Java. But you do you. Javascript all-the-way does work!

There are several ways you can structure the client and server folders, but for today’s example, we’re going to keep it as simple as possible! That way you can expand it on your own in the future!

Prerequisites
Node.js installed - You can download it here.

Get Started

First things first - let’s create our React app:

$ npx create-react-app react-node
$ cd react-node
$ yarn build

If you’ve never used npx before - it’s basically an execution library. Instead of having to install create-react-app globally and then use the global command to create the app, you can use npx!

At this point our React app is ready to go! We’re not going to do anything else with it right now since all we’re trying to do is serve it from a server.

We’ll need to add Express to our project and then create a file. I’ll name mine server.js.

$ yarn add express
$ touch server.js

Now, open the file and paste these lines:

const express = require('express');
// instantiates express so we can use the middleware functions
const app = express();

// Node’s native tool for working with files. 
const path = require('path');

// set a default port in case the host isn’t configured with one
const port = process.env.PORT || 3000;

app.use(express.static(path.join(__dirname, 'build')));

app.get('*', (req,res) => {
   res.sendFile(path.join(__dirname+'build/index.html'));
});

app.listen(port, () => console.log(`Listening on port ${port}`));

Since the file is a javascript file and we’ll the node command to start it up, the runtime is established as Node.js.

On 2 two we’ve instantiated “app” as our Express application. Just like REST requests, Express has get, post, put, and delete functions. But if you’d like to use a single middleware function for all of the HTTP verbs, the use function is your jam.

On line 6 the Express app loads the build folder. Without this line the code would fail since Express wouldn’t be able to send the index.html file to the browser.

The app.use(...) function is what actually serves the root of our React app to the browser. Notice that it’s only being served when on a GET request, but it is serving the file at all routes. This way when our React app begins routing, the server is returning the index.html file and making sure the React app is running.

To serve your app, make sure you’re in the root of the project and type:

$ node server.js

Whala! Full-stack app - done. You’re serving your pre-built React app with Express.
But let’s add one more route to make sure you’re well on your way to becoming a full-stack developer.

First, let’s add the body-parser library.

$ yarn add body-parser

Now let’s import it and setup our new route:

const express = require('express');
const app = express();
+ const bodyParser = require('body-parser')
const path = require('path');
const port = process.env.PORT || 3000;

app.use(express.static(path.join(__dirname, 'build')));
+ app.use(bodyParser.json());

+ app.post('/new-route', (req, res) => {
+   let name = req.body.name;
+   res.send(
+       {greeting: `Hello ${name}`}
+   );
+ })

app.get('*', (req,res) => {
   res.sendFile(path.join(__dirname+'build/index.html'));
});

app.listen(port, () => console.log(`Listening on port ${port}`));

This new route will take a POST request at a route matching “/new-route” and return an object with a greeting. Notice that we’ve also added another app.use(...) function that will parse the value of the body in the req object.

Now onto the React!

import React, { useState } from 'react';
import logo from './logo.svg';
import './App.css';

function App() {
 const [greeting, setGreeting] = useState('');

+ fetch("/new-route", {
+   method: 'POST',
+   headers: {
+     'Content-Type': 'application/json',
+   },
+   body: JSON.stringify({name: 'Luke Duke'})
+ })
+   .then(res => res.json())
+   .then((result) => {
+       setGreeting(result.greeting);
+   })
+   .catch(error => console.log(error))
 return (
   <div className="App">
     <header className="App-header">
       <img src={logo} className="App-logo" alt="logo" />
       <p>
         Edit <code>src/App.js</code> and save to reload.
       </p>
       + {greeting &&
       +  <h2>{greeting}</h2>
       + }
       <a
         className="App-link"
         href="https://reactjs.org"
         target="_blank"
         rel="noopener noreferrer"
       >
         Learn React
       </a>
     </header>
   </div>
 );
}

export default App;

We added the “useState” import and added a hook for the response from the server. We also added a fetch() function that POSTs into our server with a name. The JSX renders the greeting when it’s set.

Note: You do not have to return an object from the Express app. Typically real world applications return a non-string variable, but you can return any type from Express.

Finally, rebuild the React and start up the server to see your app work!

$ yarn build
$ node server.js

And that is our Javascript all-the-way example! There is a ton of great documentation on the Express.js Framework page to help you along on your way.

Stay tuned for articles on serving React with Ruby and Python.

This article is cross-posted on my website as well.