Jiffy is intended to generate a clean, straight-forward and secure application services platform just like the one you would write by hand. Jiffy originally started as a few Go templates used to generate boiler-plate code that seemed onerous to type. Generation is a lot nicer than cut-and-paste. There are places in the generated code where things could be more elegant, but the code is intended to be easy to work on even if one is not familiar with it. File and folder names are somewhat subjective; an attempt has been made to be descriptive and organized.
You are building a back-end of some sort where you need to reliably read and write data. Before you start building the ‘real’ Jiffy model of your application, try some of the demo models to get a feel for what Jiffy is and what it isn’t. It is a lot easier to design if you know what the platform provides and what it does not.
Start messing around with entity ideas. What is the best way to represent your data? Transferring your ideas into a few rough diagrams often changes your understanding of what you are modeling.
Consider the relationships you would like to have between your entities. Does your model still hold up?
Add some detail to your proposed entities in terms of fields. Remember that Jiffy will insert a primary-key (id), as well as a self-referencing entity href into the model for you. This is important when you are considering relationships, as Jiffy applications have some expectations regarding the name of the referencing field. See the Entity Relations section of this documentation set for details.
Once you are comfortable with the entities and the fields that they will contain, it is time to create the model in the Jiffy model file format.
Jiffy model files are simple JSON and at the moment need to be coded up by hand. Taking a copy of one of the sample model-files is the best way to start. Short of creating a graphical model file generator, maintaining the models via direct file maintenance is the most direct and transparent way to edit them. Remember that you do not have to put your entire model in one file. Jiffy is quite happy to accept any number of model files for your project with the entities defined in any order. The generator will sort it all out.
Check your model files as best as possible before feeding them into Jiffy. If you get an error, don’t worry; look at the error message, then check the model-file for problems. If you can’t see anything wrong, log an issue along with an example of the model-file that is causing the problem. Usual suspects for errors are missing double-quotes on field-names or string-values, missing closing parentheses on a list, missing brace on struct or sub-struct, putting quotes on a bool value, putting quotes on an int or dec value etc.
Again, don’t worry too much about formal inter-entity rules in the beginning. The idea is to get something up and running quickly so you can try out the services. You can generate your application many times over without touching anything but the model-file / model-files. Generation is fast.
Generate a version of your application and start it up. Try it out with a tool like Postman. See the Quickstart for an overview of application generation through to application testing, or go to the formal section dealing with each of the application creation steps.
It is not (typically) necessary to do early development testing via https. If this is not the case for you, see the Testing with TLS section in this document set. Step-by-step instructions are given to create and install self-signed certificates that will permit you to test locally with https.
As you test your application, you will probably see some fields missing, some fields that you don’t care for, and maybe the need for an additional entity. Update your model files and generate the application again. Try it out. Repeat.
As your model becomes more refined, consider formally adding relationships. Generate, test, repeat.
Consider foreign-keys. Generate, test, repeat.
Consider start-values for id. Not everybody is okay to start at 1, particularly if you are planning on migrating existing data into your application. Generate and test.
Consider static-queries and add the selection options to each field that can be queried. Generate, test, repeat. See the static query section for details.
Consider indices and add indexes to the model definitions where needed. Generate, test, repeat.
Access restrictions can be assigned at the end-point-level, and this is built into the generated application. Don’t worry about testing authorization and authentication for now.
When you are satisfied with your model, generate a version of the application and place it under source-code control.
Implement extension-points in the controller and model go source as per your requirements. Implemented extension-points will not be over-written should you need to regenerate the application. Test often.
Implement normalization and validation at the field-level in the generated entity model go source file. This part is slightly contentious, as field normalization and validation is performed directly in the generated code, rather than off to the side in extension-points. We suggest that if you are worried about over-writing your normalization and validation code with an accidental regeneration, you create a model_normalization package for each model and implement field-level normalizations and checks there. Of course, you are free to ignore the provided field-level normalization and validation methods and perform all checks in one of the model extension-points. Its up to you, and it will make more sense once you take a look through one of the generated files.
When you are happy with the way things are working, think about user access. Sketch out user-groups and assign end-points to them until you have something that you like. Use Postman to create UserGroups and assign Auths to them, then create new users and allocate the relevant UserGroups to their ID. That is all you need to do; the Jiffy middleware will take care of the rest. See the Access Control section for a detailed discussion of how users are authenticated and authorized.
Jiffy generated applications can be deployed in any number of ways. For example:
At the software level, the Jiffy generated application can be deployed as: