When I was a kid – crud was stuff that got stuck in the sink and needed a brush to remove – today we work with something much more positive! Create, Read, Update and Delete – is the basic building blocks of truly functional web sites and I was ready to see what I could do with VueJs. I’ve been around the block a couple times and like real life – it expanded to fill the needs that goes beyond basic CRUD examples you see out there and dips it’s toes into “real life” issues – like authentication, permissions, mobile-first design, delete vs inactivate. Read my story – or go to the bottom to see the links to run the demo or view the code.
Front-End
Building on previous VueJs work I’d demonstrated – this also uses Vue3, Vite and Pinia to build out the front-end functionality of Edit, Create, Delete (and Un-delete) of data that a backend provides. Each component was designed with the browser emulating a smaller phone screen – so it was obvious if something didn’t work for the small screen. A version 2.0 may use “cards” – which can look good on both a small, medium and large screens.
Needless to say – the two ‘ends’ know the structure of the data and this started as a simple demonstration of that functionality that extended into authentication and permissions. Certain users can update – others can only view.
Backend-End
A standard .NET API app – Entity Framework, JWT token handling etc with the common element being the structure of the data – which in this case started with a POC (Plain Old Class) and evolved to include odd tricks because I designed a general-purpose SQL table that I wanted to use for multiple classes. Don’t do that unless you have a good reason – my reason is that I knew I’ll be building more demo’s and just wanted to reduce table proliferation on my SQL servers…
When I was starting – I was thinking big so I added class libraries to separate out the various functionality – jwt, crypto, users, data. That was an exercise in over-engineering – but I’m not really sorry – I intend to re-use them in the future.
This was an exercise in “let’s build everything from first principles – ground up” – so I won’t try to suggest that my approach was superior. (My approach certainly was not superior when it came to my data model – more on that later.)
Data
If I had wanted to make a quick little demo then this would ahve been a failure – but my goal was to learn and expand my skillset. Like a lot of projects, this evolved into working through a few little features that I wanted to get beyond simple. But for the data – yes I should have just created a simple table, made an EF model of it – and just coded the darn thing – but I decided to make something that would use a common table – and then “magically” transform it into a Json object (or list/array of Json objects) and well… you can look at the code for yourself to see how complicated that got. After doing it, I wanted to do it levering the c# JToken – (and I intend to report another time on that) – but basically it wasn’t super clean eather – mainly because simplicity was at cross purposes with the desire to build a data handling library that allows me to “code-once-deploy-many” – with only the configuration files to specify the data models. The search for flexibiility and simplicity continues…
Permissions
This was another feature that ended up within the “code-once-deploy-many” goal. Because I hadn’t settled on a user infrastructure – and I really didn’t want to add another database structure to this demo – I made the users dynamically from a string in configuration. Pros-and-cons for sure – and those users had to hold the permissions for data elements and because I was determined to not add extra tables (ie normalized permissions that a fully functioning database would typically provide), they ended up being config strings inside of config strings. A kludgey solution that I’d not recommend for a real database oriented backend.
JWT & Crypto
This was demonstrated in my earlier Json Web Token demo: https://demo.northberry.net/jwt – what is different was that I moved them into two separate projects to keep code “clean”. In hind-sight – that was probably overkill – a simple folder of classes probably would have sufficed. It made the testing full of references and made the project heavier and more complicated than necessary.
SQL
I love data – and so the database part was a welcome break into the fun – creating random data sets to be merged in with the real list of real songs with odd or funny names so that the data had proper publishers, creators, created & edited dates etc..
Working together
So in the real world – you don’t just have CRUD – a user needs to be authenticated (or not – as per Contact Us forms) and permissions granted and enabled/disabled as per the wishes of the site’s specs. So not only is basic CRUD demonstrated but authentication (JWT) was used to enforce a minimum permission level. I also attempt to build configurable permissions (via web.config) from ground up on first principles. After doing it I’m not sure I like it, but part of that was trying to keep the scope of a demo project low and resorting to “static” users. (Albiet configurable static users – which may be an oxymoronic phrase.)
If you look at the API backend code you’ll see that at deployment, users can be configured with access (or not) to editing features. For this example, try editing with the user “sad” and you’ll discover that editing doesn’t work! There’s a delicate play between the frontend and the backend – for example the user holds the permissions to editing, but the frontend never knows that – it just tries to edit and save and if it works – it works. This is inspiring a 2.0 version to communicate information back to the user – for a better exerience. Nonetheless – this is solved problem in more mature systems – this was simply an experiment in moving beyond basic CRUD and into practical problems of mature, fuller featured sites.
Before you look at the Code: A (non) apology for naming…
Over the years I’ve found that frameworks often usurp common names and trying to use common english words such as object, list, token, crypto, data, database etc. has regularly put me afoul of microsoft & team’s frameworks – so I INTENTIONALLY MISSPELL classes and functions. They don’t conflict with common frameworks and a lot easier to find when searching. Anyway have fun perusing the code:
The frontend code: https://github.com/gitberry/crud-demo-frontend
The backend code: https://github.com/gitberry/crud-demo-api
And to see it all work together on a real site – here’s my deployment of it:
https://demo.northberry.net/crud/
