Well, it's a product with just enough features to gather comprehensive qualitative feedback.

In practice, it's as easy to understand the concept of an MVP as it is to ride a bicycle. Let's do it then.

In this article, I am going to explain:

• What is an MVP?
• The benefits of an MVP
• How is an MVP developed?
• How would an MVP be developed if it was a bicycle?
• Why is it important to build an MVP?
• Do you have an idea for an MVP?
• FAQ

All your customers want to be heard and understood. In the world of software, there is a large number of apps and websites out there, but only a few get the attention and love of the users. So you can start by creating a minimum viable product to find out if your idea has a place in this competitive environment.

Building an MVP doesn’t really cost much. And it helps you investigate the market competition with minimum time and budget loss (in the worst case). You’ll discover the whole story, from benefits and prototype types to the common example of your future developed MVP. So…what are you waiting for?

What is an MVP?

The most basic version of a product that can be released to test a business idea is called a minimum viable product (MVP). This concept was popularised by Eric Ries in The Lean Startup. It is part of the ethos of the Lean Startup methodology. With minimal initial investment, this framework focuses on efficiency and learning from customer feedback.

An MVP is a perfect opportunity to let your potential users voice their opinions and test out a product before its final launch. Gathering and analyzing qualitative feedback is a primary task of MVP development. Based on these findings, you can modify your MVP and test it again.

This process turns into a cycle of MVP product development which takes place over and over again until the ultimate customer satisfaction is reached.

MVPs are all about testing product ideas, analyzing user feedback, and building a full product version based on what you learn. Experts say that it's not an MVP until you can sell it in the B2B world. However, before diving into the process of how to manage an MVP, let’s learn about its main benefits.

The Benefits of an MVP

All these benefits demonstrate a strategic approach that goes far beyond just cost savings and speed to market. It's about smart, customer-centric development, where each iteration brings a product closer to the heart of what users want.

Here are some of the many benefits of building an MVP:

1. Product Hypothesis Validation

You can test hypotheses directly with MVPs. MVPs help test the market's response to a product by focusing on building core features. This process helps founders refine their business model with real-world insights rather than guesswork.

2. Minimising Capital Investment

The development of an MVP requires less investment than the launch of a fully developed end product. This approach aligns with the Lean Startup methodology, which stresses the importance of using just enough features to demonstrate the concept without overburdening resources. It allows startups to allocate their budget more effectively and mitigate financial risks.

3. Getting Investors to Trust and Get Funded

Presenting a well-developed MVP is often crucial to attracting investor interest and raising venture capital funding. The demonstration of a working MVP helps angel investors and venture capitalists visualize the potential of a business idea, making it easier to secure start-up funding.

4. Refine for Product-Market Fit

An MVP is an ideal tool for refining product-market fit, which is a dynamic process. It allows startups to closely align their product with market needs, based on user feedback. This ensures that the final product is well-received by its target audience, increasing the potential for success.

5. Gather Customer Feedback

The key to the success of any business is gathering feedback from customer research. An MVP provides a platform for engaging early adopters and gathering valuable feedback with a focus on core features.

Such user feedback is critical for startups to understand customer needs and preferences, prioritize the product roadmap, and develop the product for greater market penetration.

Now, you are ready to face the question: “How do you manage MVP software development?”.

Stages of MVP development

How to Do MVP Software Development

Every product is different, and so is the process of its development. Before we jump into the details of how an MVP is created, I want to point out that it is an individual and iterative process.

Product Discovery

Your first task is to make your idea come to life. You can start by running product discovery. You need to study the needs, interests, and demographic characteristics of the target audience. Also, analyze the strengths and weaknesses of competitors.

You will then need to go through all the features that can be implemented and select the essential ones. The next thing is to organize this information and present it during the workshops with the help of graphs, charts, tables, or any other form of visualization that you feel best represents the data.

Now, your idea should seem clearer but it is still not presentable.

Proof of Concept

Next, you need to create a Proof of Concept. Basically, this is aimed at summarizing the discovery stage and verifying that your innovative idea can be implemented in real life.

Ok, you know that your idea is feasible and comprehensive. You know that it can be done – but how?

User Journey

Now you need to understand what the user wants to see once they open the application. One of the starting points for an MVP is having a strong sense of your customer. Startups should carefully build a target user profile, taking into account various factors that affect buying decisions and product usage.

To build this target user profile, you have to identify the following:

• Industry: the type of sector your product serves.
• Pain problems: challenges your product aims to solve.
• Buying decisions: How they make their decisions and what channels they prefer to use.
• Contexts: In which way they would use your product.

To do this, you need to map a user journey. User journeys are a visual representation of a potential user and their experience with your app. They cover everything from the moment the user realizes they need this service, to the moment they first find and click through to your app, to the moment they decide to make this service part of their lifestyle.

User journeys resemble a set of statements, which look something like this:

As a [user role], I want to do [functions] so that [goal].

For example, "As a website admin, I want to be able to add or remove users to keep the app free of spammers". Or, "As an unregistered user, I want to be able to open a menu so I can understand what the application offers before I sign up.”

Prototype

After that, it's time to start prototyping. A prototype is a simplified version of the product. It demonstrates the final product design and navigation. Basically, it is a set of pictures of the interface of your future app. If it is clickable, you can navigate between screens by clicking buttons to understand user flows.

Prototypes may even look like a very basic version of your platform or mobile app. It is not a final product and not an MVP because you cannot show it to actual users.

Here, you have your idea implemented. Kind of. It can be shown to all the stakeholders but not to the end user as long as it is just a rough draft.

Now comes the most interesting part: you have to decide the type of MVP you’re going to use. We’ll take a look only at the 5 most popular types (but there are more). So, here we go:

Wizard of Oz MVP

This approach gives the user the illusion of a service or product that runs without any human interference – but in reality, behind the scenes, it's all done manually by people.

For example, for developing a digital assistant app, the staff will manually answer the customer instead of complex AI infrastructure. The MVP will allow you to check the standards and collect suggestions from users to make improvements without a big initial input.

Concierge MVP

Similar to the Wizard of Oz MVP, the Concierge MVP is a front for the final automated response of a manually transformed customized service.

For example, if your startup is a food delivery app, you can start by doing order and delivery management manually, rather than building a highly automated platform from the beginning. This is particularly important in customer satisfaction in industries that derive value from personalization and a human touch.

Single-feature MVPs

In the beginning, you shouldn't try to put together a product with too many features. Instead, develop and release just a single core feature that solves a problem. This will allow you to quickly test the pricing proposition of the product and gather customer feedback for improvements.

In general, prioritizing central functions can speed up development and reduce the likelihood of building redundant skills.

Pre-Order MVP

This involves placing pre-orders before developing or producing an actual product. With interest and pre-order funding, early sales can be used to help generate visibility and improve the product. This method reduces the chance of developing something that is not going to fit into the market and is perfect for fast iterations based purely on real names.

Minimum Viable Demos

You can also put something together that demonstrates your central price proposition but isn’t a totally functional product. This could be a model, a prototype, or an interactive presentation that shows what the product could do, rather than reserving funds for full improvements.

A basic live demo will allow you to make sales to traders, get initial stakeholder comments, and test the market functionality of your idea. This is a very strong way to test concepts before committing any resources to development.

As soon as you have all the info we can continue our journey. This is only a beginning. So, let’s take a look at the next phase.

Minimum Viable Product Development

At this stage, you need to make some ultimate decisions about the UI/UX and finalize the visual design. After that, it's time to start coding the minimum viable product.

The Minimum Viable Product looks like a final app and feels like a final app. But it has fewer features, the design or performance is not necessarily production quality, and the code quality may be lower. Your idea is presented, you've put in the code, and it's partially implemented – it's now ready to meet its first user.

Minimum Viable Product Launch and Testing

After you finish development and launch the MVP, you should present it to a sample set of actual users. Throughout the next few days or weeks, you'll gather customers’ feedback, analyze the results, and modify your MVP accordingly.

Once you see that your customers are fully satisfied, you can start implementing the final product.

Example of Developing an MVP – Let's Build a Bicycle

Let’s imagine that you want to create a bicycle. A cool, stylish, hardwearing, and sustainable bike. But what if a potential client can't figure out what you have in mind and you lose all your hard work? What if you need cash and you have to convince your investors that your idea is viable? Well, it's time to build an MVP.

The development process will be pretty similar to what I described earlier. So let's go through it with this example product to see how everything works.

Product Discovery:

You conduct a discovery stage: learn about what a bike is, what parts it consists of, what bikes people like, and what riders complain about. How can you make your bike stand out?

Through studies and marketplace evaluation, you discover insights into customer alternatives and pain points, and lay the groundwork for using new techniques. After that, you answer the most important question: what you can do to make your bicycle stand out among all the others?

Proof of Concept:

Let’s say you found out how to create a bicycle chain that never falls off the chain ring. Once you have a clear idea of how to do this, you create your mechanism: a chain, with a chainring and pedals – your proof of concept.

With a clean idea in hand, throw your concept out there to investors. You tell them more about your idea, and receive their approval and support to keep going with the project.

Prototype:

But it's not quite time to build the final bicycle, as you have not seen it yet in its actual size. So now you create a full-scale copy of the bicycle, carefully choose all the colors and materials, and make it resemble a real product.

Still, the pedals won’t spin yet, and you won't be able to steer or actually ride it. This is your prototype – looks pretty impressive and realistic but does not work yet.

MVP Development:

Your investors again review the idea and approve your design, but now they need to see the functionality. You again create a full-scale bicycle, and now it has working wheels, pedals, brakes, gears, and a seat. That is going to be your MVP.

At this point, you can let your users try it out. They get on a bike, test it, and share their opinion with you. The more people try it, the more complete your feedback is. Just be sure not to show your bicycle to people you do not trust, or they might leak your idea to a next-door producer who also makes bikes for a living.

MVP Testing:

Finally, you modify your product based on what your customers have to say until you are sure that you've got it right. Each improvement brings you closer to perfection, ensuring your bike meets and beats expectations. Through rigorous testing and iteration, you build a product that not only meets your goals but also delights with functionality and format.

Final Product Development:

Only after all these steps, when you have received financial support from your investors and the approval of your customers, are you ready for the launch.

You change out the wooden seat for a cushioned one, install safety lights on your bicycle, lubricate the bicycle chain, put on stickers and a bell, and start selling your product. A strong advertising and promotional campaign announces the arrival of your product. The culmination of creativity and hard work marks the start of a new technology in the world of cycling.

Why is an MVP Important?

A Minimum Viable Product has one main advantage, but it's a very important one: it allows you to test your future product in real-life settings with actual users.

This simple benefit has a lot of positive consequences:

• An MVP lets you adjust your product development plan before it's too late.
• It serves as a warning for any mistakes you make or as confirmation for good business decisions.
• This approach saves you a great deal of time, effort, and money by optimizing the planning process and reducing risks.
• A Minimum Viable Product boosts motivation because the team knows that what they do matters.
• MVP development offers a unique experience of testing the product idea, which will definitely come in handy in your professional life in the future.
• The MVP approach can and should be used within industries of all sorts. While for manufacturers of traditional goods it's a long and strenuous process, for software developers it can be rather simple and accessible.

Some businesses may choose to disregard the minimum viable product stage when creating something innovative – and that may be understandable in certain spaces. But in my opinion, for a software development company it's detrimental.

Once a team has launched a Minimum Viable Product, they can decide whether the venture is on the right track. The most important outcome of an MVP is to get valuable statistics from early users. It's the customers who provide information about the first-class performance of the project. The statistics you get can be used to plan future improvements and prioritize which features should be implemented first.

If you decide to take a risk and implement your idea before checking in with your target audience, you're potentially placing money, time, effort, energy, inspiration, and supporters on the line.

Do you have an idea for an MVP?

My company Covent IT is experienced in developing Minimum Viable Products. In case you need a free estimate for a similar project, feel free to get in touch.

If you have enjoyed the article, you should continue with How IT Outsourcing Saves Costs for Your Company and Avoiding Pitfalls in IT Outsourcing: Tips for Minimizing Risks.

FAQ

How to spend fewer resources

Remember that you should create an MVP with a minimum of time, money, and effort. Think about how you can spend less and still effectively test your business idea. Discussing this question will usually help you choose the MVP functionality to implement in the early stages of new product development.

How do you interact with users?

One of the main goals of creating an MVP is to test your hypotheses and determine the need and value of the product. Feedback from the first users of the product helps you achieve this goal. In order not to miss any important information, think about how you will interact with the target audience: through reviews, surveys, direct interviews, and so on.

How do you make the first sales of a product?

The first sales of the product will give you the means to develop it further and to see if there is interest in your product. You could also consider organizing a pre-sale on a crowdfunding platform such as Kickstarter.

How do you promote a product?

Plan the promotion campaign and the channels you will use. Google Adwords is usually the main tool. Then choose social networks (Facebook, Instagram, and so on), create official pages, and start targeting. You can also collect feedback on social networks.

In this course, you will learn how to quickly build an MVP for your application.

Ania Kubow teaches this course. Ania works for freeCodeCamp and has her own popular YouTube channel where she creates courses on a variety of technical topics.

In this course, you will learn why MVPs are important and how to easily create one with the Retool platform. You will learn to create an MVP that interacts with a database, uses APIs, and allows users to upload & send messages. And the skills you learn can apply to many other types of applications.

Retool provided a grant to make this course possible. Learn more at https://retool.com.

Here are the sections covered in this course:

• What is an MVP?
• Why is an MVP useful?
• Getting started with Retool
• Adding components
• Adding MongoDB database
• Inserting data
• Populating feed with data
• Updating CSS
• Adding a trigger
• Create timeline of posts
• Add messages feature
• Add upload feature
• Configure Amazon S3
• Create uploader
• Conclusion

Watch the full course below or on the freeCodeCamp.org YouTube channel (1-hour watch).

We will explore two variants of MVVM (there is not just one way to do it), and the reasons why you may prefer one variant over another, based on project requirements.

MVVM vs MVP/MVC?

It is quite likely that the most common question I am asked during my live Sunday Q&A sessions, is something like:

MVVM vs MVP/MVC?

Whenever I am asked this question, I am quick emphasize the idea that no single GUI architecture works great in all situations.

Why, you may ask? The best architecture (or at least a good choice) for a given application depends strongly on the requirements at hand.

Let us briefly think about what this word requirements actually means:

• How complex is your UI? A simple UI does not generally require complex logic to coordinate it, whereas a complex UI may require extensive logic and fine-grained control to work smoothly.

• How much do you care about testing? Generally speaking, classes which are tightly coupled to frameworks and the OS (especially the user interface) require extra work to test.

• How much re-usability and abstraction do you wish to promote? What if you want to share the back end, domain, and even presentation logic of your application across different platforms?

• Are you by nature pragmatic, perfectionist, lazy, or all of the above at different times, in different situations?

I would love to write an article where I discuss in fine detail how MVVM works with respect to the requirements and concerns listed above. Unfortunately, some of you have likely been mislead into thinking that there is only one way to do MVVM.

Instead, I will discuss two different approaches to the general idea of MVVM which present very distinct benefits and disadvantages. But first, let us start with the general idea.

Thou Shalt Not Reference Thy View Classes

For my friends who cannot read old English: “You may not reference view classes."

Apart from using the name ViewModel (which itself is confusing if the class is full of logic), the one iron-clad rule of MVVM architecture is that you may never reference a View, from ViewModel.

Now, the first area of confusion can arise from this word “reference,” which I will restate using several different levels of jargon:

• Your ViewModels may not possess any references (member variables, properties, mutable/immutable fields) to any Views

• Your ViewModels may not depend on any Views

• Your ViewModels may not talk directly to your Views

Now, on the Android platform, the reason for this rule is not simply that breaking it is bad because someone who seems to know about software architecture told you it is bad.

When using the ViewModel class from Architecture Components (which is designed to have its instance persist longer than the Fragment/Activity lifecycle when appropriate), referencing a View is asking for SERIOUS MEMORY LEAKS.

As for why MVVM in general does not allow such references, the goal is hypothetically to make both the View and the ViewModel easier to test and write.

Others may also point out that it promotes reusability of ViewModels, but this is exactly where things break down with this pattern.

Before we look at the code, please note that I personally do not use LiveData in my own production code. I prefer to write my own Publisher-Subscriber Pattern these days, but what I say below applies to any library which allows for the PubSub/Observer Pattern link from the ViewModel to the View.

This article is accompanied by a video tutorial covering many of the same ideas here:

ViewLogic + ViewModel or View + ViewModelController?

When I said “break down” in the previous section, I do not mean to say that the pattern literally breaks. I mean that it breaks down into (at least) two different approaches which have very distinct appearances, benefits, and consequences.

Let us consider these two approaches, and when you may wish to prefer one over the other.

Boromir explains that MVVM is not a magic wand that makes your application's presentation logic disappear.

First Approach: Prioritize Reusable ViewModels

As far as I can tell, most people who implement MVVM make it a goal to promote re-usability of ViewModels, so that they may be reused for n number of different Views (many-to-one ratio).

In simple terms, there are two ways you can achieve this re-usability:

• By not referencing a specific View. Hopefully this is not news to you at this point.

• By knowing as little as possible about the details of the UI in general

The second point may sound vague or counter-intuitive (how can it know anything about something which it does not reference?), so I think it is time to look at some code:

class NoteViewModel(val repo: NoteRepo): ViewModel(){
    //Note: you may also publish data to the View via Databinding, RxJava Observables, and other approaches. Although I do not like to use LiveData in back end classes, it works great with Android front end with AAC
    val noteState: MutableLiveData<Note>()
    //...
    fun handleEvent(event: NoteEvent) {
        when (event) {
            is NoteEvent.OnStart -> getNote(event.noteId)
            //...
        }
    }
    private fun getNote(noteId: String){
        noteState.value = repo.getNote(noteId)
    }
}

While this is a very simplified example, the point is that the only thing which this particular ViewModel exposes publicly (other than the handleEvent function), is a simple Note object:

data class Note(val creationDate:String,
                val contents:String,
                val imageUrl: String,
                val creator: User?)

With this particular approach, the ViewModel is well and truly decoupled from not just a particular View, but also the details, and by extension, presentation logic of any particular View.

If what I am saying still seems vague, I promise it will be clear once I describe the other approach.

Although my earlier heading, “ViewLogic + ViewModel…” is not meant to be used or taken seriously, I mean that by having very decoupled and re-usable ViewModels, we are now depending on the View itself to do the work of figuring out how to render/bind this Note object on screen.

Some of us do not like filling View classes with Logic.

This is where things get very muddy and dependent on project requirements. I am not saying that filling View classes with logic such as…:

private fun observeViewModel() {
    viewModel.notes.observe(
        viewLifecycleOwner,
        Observer { notes: List<Note> ->
            if (notes.isEmpty()) showEmptyState()
            else showNoteList(notes)
        }
    )
   //..
}

…is always a bad thing, but classes which are tightly coupled to the platform (like Fragments) are difficult to test, and classes with logic in them are the most important classes to test!

In a word, it is a failure to apply what I consider to be the golden principle of any good architecture: Separation of concerns**.**

My personal opinion is that it is worth it to apply separation of concerns to a very high degree. But make no mistake that plenty of cash cow applications have been written by people who do not have the faintest clue about what that means.

In any case, the approach we will discuss next, while having its own side effects, once again removes the presentation logic from the View.

Well, most of it anyways.

Second Approach: Humble View, Control-Freak ViewModel

Sometimes not having fine-grained control over your Views (which is a consequence of prioritizing re-usability of ViewModels), actually kind of sucks.

To make me even less enthusiastic about applying the previous approach indiscriminately, I find that I often do not need to reuse a ViewModel.

Ironically, “too much abstraction” is a common critique of MVP over MVVM.

With that being said, one cannot simply add a reference back in to the ViewModel in order to regain this fine-grained control over the View. That would basically just be MVP + memory leaks (assuming you are still using ViewModel from AAC).

The alternative then, is to build your ViewModels such that they contain almost all of the behaviour, state, and presentation logic of a given View. The View must still bind to the ViewModel of course, but enough details about the View are present in the ViewModel that the View’s functions are reduced to one liners (with small exceptions).

In Martin Fowler’s naming conventions, this is known as Passive View/Screen. A more generally applicable name for this approach is the Humble Object Pattern.

In order to achieve this, you must essentially have your ViewModel possess an observable field (however you achieve that – data binding, Rx, LiveData, whatever) for every control or widget present in the View:

class UserViewModel(
    val repo: IUserRepository,
){

    //The actual data model is kept private to avoid unwanted tampering
    private val userState = MutableLiveData<User>()

    //Control Logic
    internal val authAttemptState = MutableLiveData<Unit>()
    internal val startAnimation = MutableLiveData<Unit>()

    //UI Binding
    internal val signInStatusText = MutableLiveData<String>()
    internal val authButtonText = MutableLiveData<String>()
    internal val satelliteDrawable = MutableLiveData<String>()

    private fun showErrorState() {
        signInStatusText.value = LOGIN_ERROR
        authButtonText.value = SIGN_IN
        satelliteDrawable.value = ANTENNA_EMPTY
    }
    //...
}

Subsequently, the View will still need to wire itself up to the ViewModel, but the functions required to do so become trivially simple to write:

class LoginView : Fragment() {

    private lateinit var viewModel: UserViewModel
    //...

    //Create and bind to ViewModel
    override fun onStart() {
        super.onStart()
        viewModel = ViewModelProviders.of(
        //...   
        ).get(UserViewModel::class.java)

        //start background anim
        (root_fragment_login.background as AnimationDrawable).startWithFade()

        setUpClickListeners()
        observeViewModel()

        viewModel.handleEvent(LoginEvent.OnStart)
    }

    private fun setUpClickListeners() {
      //...
    }

    private fun observeViewModel() {
        viewModel.signInStatusText.observe(
            viewLifecycleOwner,
            Observer {
                //"it" is the value of the MutableLiveData object, which is inferred to be a String automatically
                lbl_login_status_display.text = it
            }
        )

        viewModel.authButtonText.observe(
            viewLifecycleOwner,
            Observer {
                btn_auth_attempt.text = it
            }
        )

        viewModel.startAnimation.observe(
            viewLifecycleOwner,
            Observer {
                imv_antenna_animation.setImageResource(
                    resources.getIdentifier(ANTENNA_LOOP, "drawable", activity?.packageName)
                )
                (imv_antenna_animation.drawable as AnimationDrawable).start()
            }
        )

        viewModel.authAttemptState.observe(
            viewLifecycleOwner,
            Observer { startSignInFlow() }
        )

        viewModel.satelliteDrawable.observe(
            viewLifecycleOwner,
            Observer {
                imv_antenna_animation.setImageResource(
                    resources.getIdentifier(it, "drawable", activity?.packageName)
                )
            }
        )
    }

You can find the full code for this example here.

As you have probably noticed, we are probably not going to be re-using this ViewModel anywhere else. Also, our View has become sufficiently humble (depending on your standards and preferences for code coverage), and very easy to write.

Sometimes you will run in to situations where you must find some kind of half-measure between the distribution of presentation logic between Views and ViewModels, which does not strictly follow either of these approaches.

I am not advocating one approach over another, but rather encouraging you to be flexible in your approach, based on the requirements at hand.

Choose Your Architecture Based on Preferences And Requirements

The point of this article was to look at two different approaches which a developer can take in terms of constructing a MVVM style GUI architecture on the Android Platform (with some carry over to other platforms).

In truth, we could get more specific about small differences even within these two approaches.

• Should the View observe a field for every individual widget/control it possesses, or should it observe one field which publishes a single model to render the entire View anew each time?

• Maybe we could avoid having to make our ViewModels one-to-one, while keeping our Views as Humble Objects, simply by adding something like a Presenter or Controller to the mix?

Talk is cheap, and I strongly advise you to try and learn these things in the code so that you do not need to rely on people like me to tell you what to do.

Ultimately, I think the two elements which make for a great architecture come down to the following considerations:

Firstly, play with several approaches until you find one which you prefer. This is best done by actually building an application (it can be simple) in each style, and seeing what feels right.

Secondly, understand that preferences aside, different styles will tend to emphasize different benefits in exchange for different deficits. Eventually, you will be able to pick good choices based on your understanding of the project requirements rather than blind faith.

Learn More About Software Architecture:

Social

https://www.instagram.com/rkay301/
https://www.facebook.com/wiseassblog/
https://twitter.com/wiseass301
http://wiseassblog.com/

On June 29th, I shared the MVP of mentored.dev on Twitter–my first "real" project that was bigger than anything I'd built before and something I was excited for other people to use.

After sharing this, I received some bits of positive feedback, including a shout-out in the npm weekly newsletter.

I thought I'd share the story behind the whole process.

Origin of the Idea

I can't remember when I first had the idea but a while back when I was introduced to TwilioQuest, I thought to myself,

Wouldn't it be cool to build a "gamified" learning platform that taught you how to code?

Like many other people, I have these ideas at random times throughout my life. I keep a list of these ideas in a Trello board called "IDEAS". Looking here, I can see I notated this on January 21st, 2019.

Trello board with original idea from Jan. 21st

I knew a few things:

• I wanted it to be interactive
• I wanted it to feel like a game
• I wanted it to have quick exercises

Where to Start?

Around that same time, I was wrapping up a freelance project (porting a Jekyll theme to a Gatsby site) so I didn't feel like I was ready to start it just yet. Then, I had a conversation with @signalnerve on Twitter that sparked my motivation:

Screenshot of Twitter conversation that motivated me to start.

Build a small app–a real MVP–validate your idea and then decide if you should keep building.

So I thought, "What the heck, why not start it?"

March 2019

I used a Gatsby/TypeScript starter to kickstart the first and pushed my first commit. Originally, I named the repo "Life of Code" because that's what came to mind but later I renamed it after buying the mentored.dev domain.

Initial Wireframes

After creating the repo, I sketched up some elementary wireframes in Figma

Initial Wireframes in Figma

Once I had all this, I felt over the initial "where-do-I-begin-paralysis" and knew I needed to keep the momentum going.

Taking Input

One of the first things I tried was asking for user input and showing that in a message. This would be useful for the dialog between the narrator and the user.

Basic Dialog Working

Even though it didn't look pretty, the logic for the dialog was working! This felt like a good milestone because most of the hard stuff was done.

Narrator Character Talking

I struggled a lot figuring out the best way to get the narrator talking but after finding [react-keyframes](https://github.com/zeit/react-keyframes), I was able to figure out a solution. This was huge because previously I hadn't done much with animation.

Getting Feedback on Dialog

As stated earlier, I think it's important to get input from others. I don't know if Twitter is the best place to do it but fortunately for me, the people who responded to my request for feedback were kind.

Migrating to TypeScript

I used a Gatsby-TypeScript starter for this project because I had been meaning to learn TS. However, up until this point, I wasn't actually using TS. The files just had .ts or .tsx endings.

Before the 30th, I had mentioned wanting to learn TS and @TejasKumar_ offered to teach me by migrating the mentored.dev codebase over to TS on a Google Hangouts livestream. This was one of the coolest moments of this project. And I learned a ton.

April 2019

Adding a "Profile Card" Component

Next up after finishing the dialog part of the project, I decided to focus on the Dashboard - or the page after you logged in. I created a simple "Profile Card" that will eventually show your experience, any code-cash you have, etc.

Designing the Dashboard

In hindsight, I may have gotten ahead of myself here because I designed way more than I could implement in the MVP but at least it gave me an idea for the future. I first added it as hard-coded components but later commented out to maintain a healthy UX.

Designing the Campus Map

This took way longer than I thought. I wanted it to feel like a university campus but drew heavily from Pallet Town in Pokemon. The completed version has more but at least I had something I could add to the Dashboard. I designed all of this in Figma and exported it as SVG. Working with SVGs in React has proven to be a delightful experience.

Adding Gameplay Music

I never realized how hard it is to create or find music for a game. I ended up finding this amazing sound artist named Eric Matyas who makes music and sounds royalty-free. I wanted the audio to start automatically (because that's how most games do it) but unfortunately that is not accessible so it does not auto-play.

However, if you turn it on at the start menu or when you're playing the game, it adds a nice touch.

Changing Maps

This has to be my favorite feature I added–being able to change the map. At first, I had no idea how I was going to do this, then I thought, "why not just swap the map with another map?"

So that's exactly what I did and it worked!

I extracted the parts of the map that were clickable (like the buildings) and made it so they open up different maps. I don't know how well my solution will scale but hey, it's working right now and that's what matters.

Courses Page

One of the other challenges I faced was figuring out where and how to show the courses (i.e. the dialog with the narrator).

Same thing–I struggled with this for a bit then decided, "Let's show it in an Overlay component!"

That ended up working out well. Again, I don't know if that will scale well but it works for now.

May 2019

In May, I took a little bit of a break. I was getting married so I wanted to focus on prepping for that rather than my game. I still had ideas for things here and there but I didn't put in nearly as much time as March or April.

Even though it's difficult for me to take breaks and step away, I think it's healthy to go outside, change what you're doing, mediate, etc. As my mother always says,

Everything in moderation.

June 2019

Looking at the Dashboard I created, there was still so much left to do.

I felt overwhelmed.

"How am I going to finish all this?"

A Realization at the Phoenix ReactJS Meetup

I hadn't been to the Phoenix ReactJS Meetup in a while. My two coworkers and I decided to go hear the lightning talks.

Before the talks, we were crowded around a table, chatting about our side projects. I said I wanted to finish the MVP for mentored.dev by the end of the year.

"How much more do you have to finish?"

"A decent amount. Everything on the Dashboard page is hard-coded at the moment."

"Drop all that. Finish the core features and ship it."

Those were the wise words from my coworkers. That's when I realized they were right. I decided to cut scope and implement two last features–the streak tracker and the lesson progress.

Screenshot of the streak tracker

Screenshot of lesson progress

The streak tracker logic was buggy when I first implemented it and didn't work at all. I wasn't sure if I should only increment the streak after 24-48 hours, or just do it by the day, or what. It seemed a lot more complicated than it should have been.

I still don't know if I'm happy with the implementation. But again, it's out the door and the basic functionality works.

The lesson progress (completed - 1/3) is also rudimentary at best. Again, my focus was to get it out the door. I'll style it in the future.

Ship It

June 29th. The big day.

As I say in the tweet thread,

...It's nowhere near complete but I think this is a good stopping point to share the MVP.

A while back, I read Lean Startup by Eric Ries. One thing that always stuck with me was something he said along the lines of, "You should be embarrassed putting your product out there. That's when you know it's an MVP."

And that's how I felt! So much left to do. It's hard to even consider it a "game"–most real gamers probably wouldn't.

But that's the point–it helped lift a burden off my shoulders and step back to hear what people think.

Most people I've talked to think it's a good start and a neat concept. They're excited to see where it goes.

What I Think Worked

Reflecting on what helped me launch this MVP, a few things come to mind.

Accountability - Friends & Twitter Community

As we all know, it's very easy to silo yourself and work alone. This might work for some people and that's fine. But in my case, I think sharing this project with my coworkers held me more accountable than if I hadn't told anyone. Each week on Monday mornings, one of them would ask, "Hey Joe. Did you work on your game?"

Their interest and support meant a lot to me. They wanted to see it succeed as much as I did. That kept me going.

The other part that kept me accountable was sharing it with people on Twitter. Sometimes people would comment and other times they wouldn't. Either way, people were following along. A few would DM me asking how it was coming along.

By sharing it in public, I felt a bit of pressure (in a good way) to finish it.

Using GitHub Projects, Issues, and Milestones

I treated this project like we treat client/company applications at work. I didn't use sprints per se but I did keep a list of tasks in a GitHub Project board and then select a few and create a milestone. This made the work feel more achievable and less overwhelming.

I set up a staging environment at https://staging.mentored.dev (thanks to Netlify, this was straightforward). Then, each issue I finished, I submitted a PR to merge into staging. I reviewed and merged myself (yes, a bit silly, but good practice).

Once a milestone was complete, I merged staging into master and created a new release. This process set me up for success. I kept milestones small (something I could finish in 1-3 weeks).

Having some type of project management in place for your side project I believe will help you reach the finish line sooner.

Cutting Scope

I wouldn't have finished this MVP if I hadn't cut a lot of features. For instance, I really wanted to create a repository called "mentored-dev" after the user logged in and store the lesson progress there. But that was going to take more time than I anticipated so I cut it.

Instead, I store the progress in localstorage. Yes, it's short-term but again, I had to cut scope to ship. If I hadn't, I wouldn't have finished this phase of the project.

Closing Thoughts

Overall, I feel thankful for all the support. I'm proud of the small project I built and the feedback I have received, so thank you. As for the next steps, I've already created the next milestone. The main thing is to finish all the lessons for the basics of the command line and then share that to see what people think.

As far as actual features–I wouldn't promise anything but I'd love to add experience points (XP) which you accumulate based on your score in the lessons or how many times you take each lesson, how often you login, etc.

It would also be nice to give XP for doing things outside the game (i.e. writing a blog post, tweeting something you learned, contributing to open source, helping someone, etc). We'll see what happens though.

Thank you for listening to the journey.

###

If you enjoyed this article or found it interesting, please share it with others or let me know on Twitter.

To stay up to date on mentored.dev or other things I'm working on, I have a newsletter you can sign up for here.

Happy coding!

This article follows two others about creating Full Graph Stacks. Check out How To Build A Cutting Edge Server Now for a conceptual introduction to the approach. Launch Your MVP Server In An Hour guides you through building a stack of development quality. This article explains how to convert that stack to a robust, permanent application.

What’s Wrong with the Development Stack?

The steps in the second article mirrored the GRANDstack video:

• The database is a Neo4j Sandbox
• The APIC server runs on Now.

That’s enough for an MVP or for the initial prototyping, but you’ll have to move on soon. The biggest initial limitation is the database. The sandbox will live at most ten days.

Even after you spin up a permanent database, Now would make a difficult permanent home. In theory, it would be possible if you didn’t modify your server frequently. You could set up your permanent API with a separate host and alias it to your Now endpoint. The problem is that the Now endpoint changes each time you upload a revision. That means that you have to keep updating your alias.

Security also poses a challenge. It’s common to create a white list of IPs permitted to access your database and to limit the list to your API server. So if that server IP changes frequently, you have to update the list with each revision. I don’t see a viable way to do that with Now as of this writing. (Please reach out to me if you do!)

So the question is, what’s the best approach to solve these limitations?

On the Cutting Edge

The truth is, this article has been on hold for a few weeks. The problem was that neo4j-graphql-js was not quite ready to support production. But in the past few weeks, that all changed. The team solved a few fundamental problems:

• Middleware became supportable two weeks ago. The team added to the generated reducers support for throwing middleware errors. That enables your server to run general authentication and authorization functionality as middleware.
• Modification of mutations became possible a week ago. Until then, you were stuck with the generated mutations. Now you can add necessary business logic or side effects.
• Autogenerated keys are becoming available. The team reported yesterday a new @autogenerate directive. Placing the directive after a key will result in an autogenerated UUID. Before, the front end had to pass values in for keys, which is most unusual for a production server.

This writing, on August 19, 2018, comes in the midst of many other expected fixes. Of particular interest, the team plans to release some directives to simplify auth. Also, I hope that we will soon see nested mutations. Much of what I write here will soon become outdated. But I’ve decided that it’s worth describing this package now, because it’s already useful. Please post updates or corrections below as comments.

Options

When you leave the world of sandboxes, you have choices. I think that the general rule is that today most are fine. The important thing is to move forward.

But the three basic steps that I discuss below are probably universal needs. They may be all that you need for your back end.

Two introductory observations:

• You don’t need to get things perfect from day 1. There was a time when decisions like the size of your machine or your host had long-term significance. Today any sensible team works in the cloud. Most decisions are reversible. Auth may an exception, but even that may be changing. Get something live and start pivoting!
• If you followed the steps in Launch Your MVP Server In An Hour, you have an amazingly small back end. You will need three components: your tiny server app, your database, and an auth service. You don’t even have to store them with the same host.

Contents

1. Set up Auth
2. Spin your Database
3. Create Your Server

Set up Auth

Every project’s auth needs are different, but some basics have emerged. You need two things:

1. En external authentication service. Two common choices are Cognito and Auth0.
2. Most servers also need authorization, or access control. You have to decide whether a particular user is allowed to do something.

Setting up Middleware Capability

The preferred way to handle Auth is through middleware or directives. As of the current writing, auth is not included in the GRANDstack starter.

The server used in api/src/index.jx in the starter package is currently ApolloServer. But you can replace that with graphalExpress from apollo-server-express.

You will have to change 2 files:

• api/src/index.js
• api/package.json

You should also add an auth.js file.

Here’s a version of index.js that currently works with middleware:

import express from 'express';import { graphqlExpress, graphiqlExpress } from 'apollo-server-express';import cors from 'cors';import { makeExecutableSchema } from 'graphql-tools'import expressPlayground from 'graphql-playground-middleware-express';import bodyParser from 'body-parser';require('dotenv').config();import { v1 as neo4j } from "neo4j-driver";import { augmentSchema } from "neo4j-graphql-js";import { typeDefs, resolvers } from "./graphql-schema";import { authenticateUser, authorize } from './auth';// augmentSchema will add autogenerated mutations based on types in schemaconst schema = makeExecutableSchema({  typeDefs,  resolvers});const augmentedSchema = augmentSchema(schema);const driver = neo4j.driver(  process.env.NEO4J_URI,  neo4j.auth.basic(    process.env.NEO4J_USER,    process.env.NEO4J_PASSWORD  ));const app = express();app.use(bodyParser.json()); // support json encoded bodiesapp.use(cors());app.use('/graphql i apollo-server-expressql', graphiqlExpress({  endpointURL: '/graphql'}));app.get('/', expressPlayground({ endpoint: '/graphql' }));// app.use('/', authenticateUser, authorize);app.use('/graphql', bodyParser.json(), graphqlExpress(req => {  return {    context:  {      auth: req.auth,      driver    },    endpointURL: '/graphql',    schema: augmentedSchema  }}));app.listen(process.env.GRAPHQL_LISTEN_PORT, '0.0.0.0');console.log(`GraphQL Playground at ${process.env.GRAPHQL_LISTEN_PORT}`);

Note that:

1. We are using apollo-server-express, which supports middleware
2. Two functions are called as middleware: authenticateUser and authorize. Both definitions appear in auth.js.
3. I also added cors, which we needed to resolve some CORS issues.

The project.json file must contain the proper dependencies. As of this writing, here are the versions I’m using:

{  "name": "grand-stack-express",  "version": "0.0.1",  "description": "API app for GRANDstack with express",  "main": "src/index.js",  "license": "MIT",  "dependencies": {    "apollo-server-express": "^1.3.6",    "babel-cli": "^6.26.0",    "babel-core": "^6.26.3",    "babel-polyfill": "^6.26.0",    "babel-preset-env": "^1.7.0",    "babel-preset-stage-0": "^6.24.1",    "babel-watch": "^2.0.7",    "body-parser": "^1.18.3",    "cors": "^2.8.4",    "dotenv": "^6.0.0",    "express": "^4.16.3",    "express-graphql": "^0.6.12",    "graphql-playground-middleware-express": "^1.7.1",    "graphql-tag": "^2.9.2",    "graphql-tools": "^3.0.4",    "neo4j-driver": "^1.6.3",    "neo4j-graphql-js": "^0.1.32",    "node-fetch": "^2.1.2",    "nodemon": "^1.17.5"  },  "resolutions": {    "neo4j-graphql-js/graphql": "v14.0.0-rc.2"  },  "scripts": {    "test": "echo \"Error: no test specified\" && exit 1",    "dev": "babel-watch --exec babel-node --presets env,stage-0 src/index.js",    "start": "nodemon --exec babel-node --presets env,stage-0 src/index.js"  },  "devDependencies": {    "nodemon": "^1.17.5"  }}

Here’s a starter auth.js file to add to your project and complete:

import gql from 'graphql-tag'import { v1 as neo4j } from 'neo4j-driver';import { INSPECT_MAX_BYTES } from 'buffer';require('dotenv').config();const driver = neo4j.driver(  process.env.NEO4J_URI,  neo4j.auth.basic(    process.env.NEO4J_USER,    process.env.NEO4J_PASSWORD  ));const resolveUser = () => {  //a placeholder  return 0;}/* * middleware functions follow */export const authenticateUser = async (req, res, next) => {  req.auth={};  try {    const response = await resolveUser();    req.auth.user=response  } catch(err) {    req.error=err.message  }  next();}export const authorize = async (req, res, next) => {  if (req.error) {    console.log(req.error);    next();    return;  }  // placeholder, allows every authenticated request  next();}

1. start by committing your old version to git and probably creating a new branch. git add . then git commit -m "works without auth" and then git checkout -b auth. You will then see a response of
   Switched to a new branch ‘auth’
2. replace your api/src/index.js and api/project.json files with the versions above, and add the auth.js file to api/src.
3. move your current node_modules: mv node_modules node_modules.old
4. run npm install again, then npm start. Make sure that it works by running a query.

Add Your Authentication Service

You can fill in the details based on the SDK for whatever auth software you use.

You may have to study up on using async/await functions in an express app, but it’s not too difficult to learn.

1. Uncomment the line app.use(‘/’, authenticateUser, authorize); in index.js.
2. Install the proper Node js SDK for your Authentication service. Then add the needed code and rewrite the function authenticateUser in auth.js to call it. Remember to set req.error to an appropriate error message when authentication fails.
3. Practice by adding a valid token to the HTTP Header. Note that in Playground the HTTP HEADERS panel makes this quite simple.

Add Authorization

The file auth.js includes a database driver. The driver supports querying to determine a user’s access rights to specific data. For instance, your database could store read/write privileges for data. Whenever a request fails your test, you can specify what failed by setting req.error. The neo4jgraphql resolver function will return the error message.

Note that you can add more functions to the middleware. For instance, you might add a check whether the current user is fully paid.

Enhancing AugmentSchema

The call to augmentSchema in the index.js file generates the mutations in your schema. As stated above, a recent enhancement lets you add mutations. You can also overwrite the generated ones.

One simple way is with the @cypher directive in your mutation declaration:

type Mutation { UpdateFoo(id: ID, name: String): Foo @cypher(statement:”MATCH (f:Foo {id: $id}) SET f.name = $name”}

Then, for the resolver just use neo4jgraphql:

Mutation: { UpdateFoo: neo4jgraphql}

Database Hosting

You have some options. First, there are some hosting services. I wasn’t so impressed, because it’s not that hard to create a database server yourself. But, the cost is a drop in the bucket compared to your team’s time. If you pay a few hundred dollars a month to get something up and running, and you have no worries, you could do a lot worse.

Basic Hosting

I decided to spin up an AWS EC2 instance instead. I’m going to write what I did there.

1. Decide your region. Might not matter much, but if you are centered somewhere then go for it.
2. Get the AWS CLI working working on your computer.
3. Get hold of an appropriate AMI. You can search on the AWS store, or check out what’s available.
4. Do the steps (until the last one) here. Make sure to save your key file, as you’ll need it for setting up APOC.
5. Then you need to go to the page, log in and change the password. But which port to go to and what password might not be the same as there. For my AMI, the password was “neo4j” (like the user name). I had to go to https://[IP]:7473/browser/ (not http as in the example given on the page, and not 7434).
6. Change your code on your local to be sure that you can connect to it. Check it on your localhost:4000.

Setting up APOC

To use @cypher directives, or any of the APOC functions, you’ll have to to install the APOC jar file on the server itself. You’ll need to ssh in to your database server. As of 2 months ago, it wasn’t included in the AMIs.

1. You’ll need to use the command shown at Hosting Neo4j on EC2 on AWS: ssh -i $KEY_NAME.pem ubuntu@[PublicDnsName]
2. You’ll have to add the jar file to the neo4j plugins directory. Follow the manual instructions to find the latest release and figure out where to insert it.
3. You also need to find your neo4j.conf file and insert into it permission to call the functions. The following works: dbms.security.procedures.unrestricted=apoc.*
4. Then you’ll have to restart: sudo systemctl restart neo4j.

API Deployment

You can deploy on any system that supports a NODE js app. I used AWS Elastic Beanstalk:

1. Run the command zip -r api.zip . -x node_modules/**\*in the api directory. That creates a zip without the directory itself and without the node_modules.
2. Go to AWS Elastic Beanstalk in the console and make sure you’re in your region of choice.
3. If you can get to the welcome page, I find it the easiest. You click on Get Started, and follow the instructions. They set me up right away with what I needed. You just upload the file that you zipped above.
4. nder Configuration for the Elastic Beanstalk environment, go to Modify Software. Enter Container Options, and set Node Command to npm start.
5. After about 10 minutes, it’s ready. You can click on the endpoint URL to see it.
6. Use Route53 to alias your own api domain to the Elastic Beanstalk endpoint, and you’re all set.

Conclusions

If you’ve followed this far, congratulations. You know more about how to build a full graph stack than many seasoned back end designers.

The process described in these articles might take an hour for someone who has done them a few times. For anyone else, these articles hopefully minimize the extra time to research. The development time should fall even more as these tools improve.

But simplicity and ease are just one benefit. The full graph stack is also technologically sound.

• The server created here is robust.
• A graph database in general scales brilliantly.
• The stack uses very few resources.
• You can port the back end to different hosts or services, reducing lock-in and fees.

Let us work together to keep this technology moving. Please leave comments or reach out with other improvements. Good luck with your own projects!

Building A Full Stack Server

This article guides you through creating a live, development quality API and back end. It should take you about an hour. And, by the way, it will be free!

This is the second of a series of 3 articles about full graph stacks. Check out How To Build A Cutting Edge Server Now for an introduction.

I’m assuming that you know how to code, but not that you’re advanced. This is a full stack project. It touches on a lot of new tools, so you need not feel intimidated if you don’t understand everything. You’ll have some learning curves ahead, but not too steep.

The idea, as explained in the first article, is to focus on specifying your app’s graph of data types. Then to use new tools that generate an app from it.

As I wrote in the first article, I went with the GRANDstack project. I don’t claim that it’s the only viable approach, but I recommend that you at least check it out. My team decided on our own that we wanted to go with React, GraphQL, Apollo, and a graph database. The GRANDstack consists of these exactly, so the discovery excited me.

But the real excitement begins with the package neo4j-graphql-js. It generates (Prisma style) a set of mutations and resolvers from TypeDefs. If you don’t know what that means, read on.

On the GRANDstack Kickstarter page, a video shows how to create a full stack from start to finish. That was where I started.

One problem with writing these articles is that featured packages are under development. Many things that you still need to do today may be automatic within weeks. I want to summarize the steps and explain how to do some of the things you need that are still missing. But the staff at Neo4j is working on them. If you see that this info is outdated at any point, please post an update below.

Alternative Approaches

Before we start, let me repeat that I’m not calling GRANDstack the only or even the best approach to a Full Graph Stack.

Many alternatives use Prisma to convert a GraphQL schema to an underlying database. Make sure to check out GraphCool. As of this writing, these systems are more developed and leave less work for the developer. A good example is auth.

The Prisma approach also has less lock-in to a particular database. In practice, changing the database wouldn’t be that hard with GRANDstack. But the cipher queries and the directives are unique to Neo4j.

That said, the GRANDstack Project is explicitly focused on the idea of a Full Graph Stack. I recommend them because they are responsive and devoted to the vision. It is also very straightforward.

Setup

Create a Project

1. Download the starter. Click DOWNLOAD STARTER from GRANDstack, or download it from their GitHub page. I used the GitHub page to be sure I had the latest version (it should be anyway).
2. Unzip to a folder and name it for your app project
3. It is wise to move the new app folder to a general project folder.

Set up Git

I recommend that you not do a thing until you start using Git to handle version control.

1. Install Git if you don’t have it.
2. In a text editor, modify .gitignore in the root project directory to include under #dependencies a line for api/node_modules and a line for ui/node_modules. As of this writing, .gitignore contained only node_modules.
3. Move to the root directory of the project in a terminal, and create a new git project:

git init git add .   # adds the relevant filesgit status  # optional to view the files if you are interestedgit commit -m “Initial App Files” #or whatever name you'd like

You can perform git add . and git commit -m "some description" as often as you like. See the endless documentation about Git online. You can learn about branches, commits, reverting, and everything about version control.

Make the Sample Back End

Note that your project code has two directories: api and ui. These articles only focus on the api directory, for creating an API server and back end. For more about the ui, check out the GRANDstack Kickstarter video. You can also view the tutorials at GRANDstack.

Build the Back End

You need to build the code. You can use npm for that. In the terminal, move to api, and perform these steps:

npm install # pulls in all of the node modules needed for the apinpm start # begins the app

That should initiate the app. You should see something like this in your terminal:

$ npm start

> grand-stack-starter-api@0.0.1 start /home/israel/projects/events2/api> nodemon --exec babel-node src/index.js

[nodemon] 1.18.3[nodemon] to restart at any time, enter `rs`[nodemon] watching: *.*[nodemon] starting `babel-node src/index.js`GraphQL API ready at http://0.0.0.0:4000/

Open that link, and you should see a GraphQL Playground page.

You can click the green SCHEMA tab on the right, and you’ll see a schema for a sample database. The only thing you’re missing is the database itself.

Set up a sample database

You’ll have to register with Neo4j to use their sandbox in the steps given below. I recommend getting onto their Slack channel from the beginning. In particular, if you follow the steps below I’d join the #grand-stack channel so that you can ask questions. The project is evolving quickly, so it’s important to stay connected. They are pretty receptive to ideas and responsive to problems. In the past few weeks, they’ve implemented several ideas that I and others have proposed.

Spin up a Blank Database

1. Login at Neo4j Sandbox. (As stated at the beginning, you need to create an account if you don’t have one.)
2. Find “Blank Database” and click on it. It should generate and show up after a minute under Your Current Sandboxes.
3. Click the Details tab, and you’ll see something like this:

You’ve now generated a live database. You can visit it in the browser at the top link.

Connect Your Project to the Database

Open the api/.env file, which contains some global variables used in the API:

NEO4J_URI=bolt://localhost:7687NEO4J_USER=neo4jNEO4J_PASSWORD=letmeinGRAPHQL_LISTEN_PORT=4000GRAPHQL_URI=http://localhost:4000

You need to set some of these from the Details tab of your sandbox

1. Copy the IP Address (e.g. in the example shown above it is 174.129.54.148), and then the bolt port e.g. 33199. Use them together to create a new value for NEO4J_URI in the api/.env file, replacing bolt://localhost:7687. Note that a colon separates them. E.g. the first line in this case would be NEO4J_URI=bolt://174.129.54.148:33199.
2. Also, copy from Details the sandbox db password (e.g. in this case adhesives-casualties-loads) and replace the default password letmein.
3. Of course, make sure you’ve saved your changes. Then return to your terminal, hit ctrl-c, once again enter npm start, and return to http://0.0.0.0:4000/ and reload.
4. Now enter the following mutation in the left pane:

# Try to write your query heremutation {  CreateUser (id: "borris", name: "borris the spider") {    id  }}

Hit the arrow button in the middle to execute, and you should see the results of the mutation in the right button:

If so, congratulations! You already have a functional API server running locally.

Don’t forget to commit your changes to Git. Back in the root directory of your app (not in API), enter:

git add .git commit -m "Working Sandbox Db"

Inspect the Data Directly

Now, click the link to Neo4j Browser at the top of the Details in your Neo4j Sandbox. (In the case shown above, it is [https://10-0-1-68-33200.neo4jsandbox.com/](https://10-0-1-68-33200.neo4jsandbox.com/.)).))

You can read about how to use it at Neo4j. But for our purposes, enter the following query at the prompt: MATCH (n) RETURN n. That query returns all of the nodes in the database. Click the arrow button on the right to execute, and you should see the new node that you created:

You can get back to a terminal in your api directory and enter npm seedDb if you like. After a minute or so you’ll see the seed data that comes with the starter package for their sample database. You can then play with Playground making queries like this:

{  users(name: "Will") {    id    name  }}

Or, you can just move on to the next step.

Add your Own GraphQL Schema

Click on the green SCHEMA button in the Playground interface. You will see a schema that came with the sample database:

Now it’s time to replace that with your own schema.

1. Open the current sample schema api/src/graphql-schema.js, and see the source for that data. It’s in the typeDefs declaration.
2. Learn minimally what you must about GraphQL Type Schemas. You must be able to implement your own needed types and some queries. It’s straightforward.
3. Start with one or two types and experiment, building it up gradually. To create a query, you’re going to have to change both typeDefs and resolvers (beneath typeDefs in the same file). Fortunately, your resolvers will be simple. Just call neo4jgraphql from the neo4j-graphql-ps package, as in the sample database.
4. Save changes to the file, and confirm that npm is updating. Then refresh the Playground tab and confirm that the new Schema is showing up.

The introductory article about full graph stacks mentioned a sample app for events. Here was its sample app data type graph:

That’s a lot to add all at once, but it’s not hard to start. We work from the top down, and GraphQL is extremely forgiving.

Understanding neo4j-graphql-js

It would help to understand a bit about how the server uses neo4j-graphql-js.

The call to augmentSchema in index.js is what is creating all the mutations. That includes the CRUD functions (Create, Update and Delete) for each of the types created. Also, the Add and Remove functions for creating relationships.

Relationships between types generate relationship functions. When a type X returns Type Y as a field, that indicates a relationship. Add and Remove functions are generated when the precise relationship is defined using:

1. a @cypher directive or
2. a @relation directive with a direction of “OUT”.

The other important function is neo4jgraphql, which implements a resolver. The documentation of the package explains the details.

The documentation was updated just last week on the GRANDstack documentation page. (This writing is August 19, 2018). The documentation is still a bit minimal. For instance, the critical augmentSchema function is not discussed in the documentation. They do discuss mutations and they show an example using it. But the documentation is helpful. So are the examples contained in the starter package and in the examples brought there.

You might also check the documentation for [neo4j-graphql](https://github.com/neo4j-graphql/neo4j-graphql). but some things there may not have made it into the ps version yet.

Initial Changes

You can remove all the types in the example, but note that you should not entirely remove the Query type. You will need it for your queries, as you can see in GraphQL documentation.

Here’s an example of the simplest possible beginning for the events app schema:

export const typeDefs = `type Event {  id: ID!  name: String}type Query {    events(id: ID, name: String): [Event]}`;export const resolvers = {  Query: {    events: neo4jgraphql,  }};

After saving, check for a reassuring message in the terminal where npm start is running. Something like this:

[nodemon] restarting due to changes…[nodemon] starting `babel-node src/index.js`GraphQL API ready at http://0.0.0.0:4000/

Refresh Playground in the browser and clicking the SCHEMA buttons. You should see the new schema:

You can then start adding more types.

Add your own data

1. At your Sandbox prompt, enter MATCH (n) DETACH DELETE n. That will delete any data you added for the sample schema that came with the project.
2. Use the generated mutations in your new schema to create some data. For instance:

mutation {  CreateEvent(id: "my event", name: "The Big Event") {    id    name  }}

Go Live

The only thing left is to move your server to a live site so that your front end can call it. (Oh, and you will have to create the front end — go to the ui directory of your app folder to deal with that). The video in the GRANDstack Kickstart page recommends using Now.

Go to Now Desktop and click download. But: the desktop app doesn’t currently work for Linux. I’m on Ubuntu, so I just used their command line interface. That’s what I use in this instructions.

1. Once you’ve installed on your machine, log in. You should be able to return to the Now site and see your name or picture at the top right.
2. Go to the api directory and type now. You’ll be prompted a few times to enter things. If all goes well, you’ll get a long series of output in the terminal ending with a success message:

$ now> Read more about how to update here: https://zeit.co/update-cli> Deploying ~/projects/events2/api under xxxxxxxxxx@gmail.com> Your deployment's code and logs will be publicly accessible because you are subscribed to the OSS plan.> NOTE: You can use `now --public` or upgrade your plan (https://zeit.co/account/plan) to skip this prompt> Upload [=============-------] 66% 0.1s (192.48KB) [4 files]> Using Node.js 8.11.3 (default)> https://grand-stack-starter-api-qibrvosvuh.now.sh [in clipboard] (bru1) [7s]> Synced 4 files (192.48KB) [7s]> Building…> ▲ npm install> ✓ Using "package-lock.json"> ⧗ Installing 13 main dependencies…> Building "nodemon@1.18.1" remotely> Building "nodemon@1.18.1" remotely> Building "nodemon@1.18.1" remotely> Building "nodemon@1.18.1" remotely> Error: Error parsing `package.json` for nodemon-1.18.1.tar>     at extract (/snapshot/ace/lib/extract.js:36:11)>     at process._tickCallback (internal/process/next_tick.js:188:7)>     at <anonymous>> ▲ npm install> > protobufjs@6.8.6 postinstall /home/nowuser/src/node_modules/protobufjs> node scripts/postinstall> > > nodemon@1.18.1 postinstall /home/nowuser/src/node_modules/nodemon> node bin/postinstall || exit 0> > Love nodemon? You can now support the project via the open collective:>  > https://opencollective.com/nodemon/donate> > npm WARN grand-stack-starter-api@0.0.1 No repository field.> npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.4 (node_modules/fsevents):> npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.4: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})> > added 564 packages in 9.426s> ▲ Snapshotting deployment> ▲ Saving deployment image (9.0M)> Build completed> Verifying instantiation in bru1> [0] > [0] grand-stack-starter-api@0.0.1 start /home/nowuser/src> [0] nodemon --exec babel-node src/index.js> [0] > [0] [nodemon] 1.18.1> [0] [nodemon] to restart at any time, enter `rs`> [0] [nodemon] watching: *.*> [0] [nodemon] starting `babel-node src/index.js`> ✔ Scaled 1 instance in bru1 [13s]Open that url, and you should see your playground. Try it to be sure that it’s working:

The most important thing is a line indicating your live endpoint:

https://grand-stack-starter-api-qibrvosvuh.now.sh [in clipboard]

Open that URL, and you should see your playground. Try it to be sure that it’s working:

What You Have Achieved

That’s it — a live development server, with very little time and no money down! You have a full stack. But unlike a LAMP stack, this stack includes the API itself. Note that all you had to modify was was typeDefs and resolvers.

Understand that this is not yet production quality:

• Your time is very limited to use this without setting up a permanent database. You can now play with this on your front end until your Neo4j Sandbox expires. That will be 3 days, but you can request an extra seven. And of course, you can always create a new Sandbox. If you like, you can also store a set of mutations at api/src/seed/seed-mutations.js. You can run it with the command npm seedDb whenever you change to a new sandbox.
• Whenever you want to change your version on now, the URL will change. You can set up an alias to allow your code to handle that, but it’s not ideal long-term.

But for an MVP, and for initial development, it is enough and is free. If you have a domain, you can use any hosting service set up a CNAME record to run your Now page from it.

Check out Making Your Full Graph Stack Production Quality to learn how to deploy for release.