Use cases for Magic

I have just been getting some interesting feedback on Magic, basically saying “We love Magic, but it’s not something we’d use in production”. This argument originates from a misunderstanding, believing that Magic could replace your other development efforts, and that it allows you to deliver a production ready application, by simply clicking a button – Sorry, it can’t!

The CRUDification process in Magic is simply not flexible enough to replace your existing development department, and it probably never will either. However, that’s not the use case for Magic, and it never was intended to be either.

Magic has many interesting use cases though, also in production, so I’ll try to pinpoint some of these here.

  1. A “secondary app” for enterprise developers, allowing you and your colleagues to gain more “raw” access to the database. Either because of support issues requiring more raw access to the database, or because of needs to configure your database. This is work we as developers normally have to do through Microsoft SQL Management Studio. By having a Magic app accessing your database, you can let others do this work, such that you as a developer can focus on more interesting things.
  2. “Micro service” for your other apps, allowing you to create several smaller apps, such as for instance translations HTTP endpoints, etc.
  3. Authentication and authorization. If you go to the dotnet subreddit on Reddit, 25% of all questions are asking about how to secure your web API using .Net Identity. By creating a Magic app, and using this as a single sign on app for you other apps, you can simply skip this step in your app’s requirements. This also gives you a nice GUI from where you can administrate your users and roles. Rolling your own auth server with all these features, would at least take you weeks of development – In addition to that it would highly unlikely be as secure as what you could do in Magic in some few hours of development during an afternoon.
  4. Using Magic as a Starter Kit. There is nothing preventing you from adding any amount of .Net Controller endpoints to your Magic app, and pull in Entity Framework, and all the other stuff you’re used to from .Net Core. This gives you a starter kit for your new projects, allowing you to much more rapidly get up to speed when creating new apps. While at the same time keeping your exact same development process as the one you’re used to. Things you’d get out of the box here, are auth, database audit logging, scheduling tasks, etc, etc, etc – All of which are things you can already as you start out, check off from your existing TODO list.
  5. An enterprise cloud dashboard. If you connect Magic to a database, and CRUDify it, you already have complete access to your database, kind of like PHPMyAdmin gives you – Only much simpler access of course. If you wrap a GUI on top of it, you can allow your non-technical colleagues to access it, without fear of them destroying your data in any ways. In addition, Magic gives you a file browser to see the files on your server. It gives you a GUI for your log, which you can even set in auto-pulling mode, and display on a monitor in your development department, etc, etc, etc. In many ways, Magic gives you (more) than what cloud vendors, such as Azure and Amazon gives you.

Hopefully, this (incomplete) list gives you an idea of why Magic matters 🙂

Published by servergardens

Create .Net Core CRUD APIs wrapping your SQL database in seconds