I am setting up a DTAP environment for Google App Maker. Google App Maker enables working in a singe file very well, however there is one use case that I would like to simplify.
For each deployment I need to "know" certain things in the back end script. Things like the ip address of the SQL server, or usernames and passwords. This information needs to be retrieved fast and often, given the stateless nature of google.script.run.
The best solution so far is a settings form, combined with google drive tables and caching. This works, but it is not simple, and things could fail easily. The other approach is hard coded and linked to the deployment url. This is fast and simple, but also means that all the credentials are in the source.
I am looking for a better solution. Apps Script used to have the script properties. Is there a similar option in App Maker, with a UI to maintain the settings.
There is no built-in UI to manage script properties, but App Maker's runtime (Apps Script) provides API to perform CRUD operations on it:
PropertiesService.getScriptProperties().setProperty('testKey', 'testValue');
...and you can 'easily' build the UI on top of this API. In answer for this question are highlighted major steps to achieve this: Google App Maker how to create Data Source from Google Contacts
Here is a feature request for the first party support. You can up-vote it by giving it a star:
https://issuetracker.google.com/issues/73584947
Related
I have a CI/DC pipeline with google cloud build triggers that deploy my code to different sites depending on which branch I push to. The develop site is a live test - the final check before I merge to master, which triggers a deploy of master to the production site.
Currently, both sites use the same firebase Firestore db, and any document changed on the develop site will also be changed on the production site.
What I want to avoid is creating another firebase project to push the develop code to with a different database, because that means I need a separate set of credentials and would copy the same functions over to the new project every time I change them. That's not maintainable and is a lot of work.
What I would like is some way for the develop site to only have access to part of the firestore database, and the production site to have access to another part.
How do people do this? Is it even possible? Is there a better way? One alternative I can think of is using authentication and creating separate accounts for testing with different access permissions, but this seems a work-around and not the ideal solution.
What you're trying to do sounds like a lot more hassle than using multiple projects, which is the documented and strongly preferred solution. Putting everything in one project is a huge anti-pattern in Firebase and Google Cloud, and it will cause you more problems in the long run, in addition to increasing the risk of catastrophic failure if you manage to misconfigure something in that one project.
It's perfectly maintainable to have multiple projects like this, if you apply some scripting to automate the work. This is very common, and I strongly suggest thinking through how this would work for you.
You CI/CD pipeline could definitely check out your updates from source control and deploy them to whatever other project environments you have set up. It's very common to manage different credentials and configurations for use in CI/CD.
We currently have an application that is usable by several clients, it is used to download and store data from our application that they have on their environment.
We have a need to pass this application over to a developer but at the same time, we need to protect our code. The way that I see it working is that we would like to some how consider our current app a framework, allowing another app to be created on top of it, but the app may have its own screens, but re-use some of the built-in screens.
Is it possible to protect our app in such a way with out rewriting everything into protected DLL's? Or should we just suck it up and share our code with consulting firms that want to build these types of apps for our clients?
If your proprietary code is entirely focused on downloading and storing data. You could create an online REST api that returns the data over the internet. The other developer could then just request the data from your servers using an HTTP call.
However if your code needs to be client-side, the only real thing you can do is compile a DLL, and even then that can be decompiled.
Will it be a good idea to create a completely "serverless" app using Appsync/Firebase when fine-grained access control is necessary?
I tried to build an app with Firebase, and then with AppSync and it feels like these solutions are kind of crippling me, and I started to think that maybe im still thinking in the "old" way of solving the problem, and that's what is crippling me and not the tools.
Where im struggling is with access control.
Firebase has "Firebase rules" and AppSync has "VTL"(Apache Velocity Template Language), both offer relatively good solutions, "Firebase rules" is easier and cleaner, but VTL is more robust because it is basically a programing language.
The problem is that im trying to give the user access to documents on the database based on a "collection/table" of permissions. So each user has a document inside that "collection/table" with fine-grained permissions, and I need to read that document in order to know if he has access to the resource he is trying to read/write.
With both, firebase and AppSync I can read the DB, but both have their limits:
Firebase Rules has request limits. and that is problematic if a user
has multiple "permission groups".
AppSync is more flexible, but still limited, and I rather use my language of choice rather than VTL if im going to write some logic. And in addition, I rather have that code inside my project locally than only in the cloud accessible via the GUI.
So, in the end, it feels like both solutions drive me into having another layer before them in order to do more complex stuff, so it can either be functions or an entire app.
But then, why do I need all of their APIs? Having another layer before Appsync/Firebase basically forces me to reimplement GraphQL/Firebases API, and then, why not build it using another tool?
So, am I doing it all wrong? Will it be better to have an app deployed on AppEngine or a similar solution(and thus losing the advantages of functions)?
Note: Im sorry if after all this reading its still not clear, English is my first language.
AWS AppSync added Pipeline Resolvers recently, which sounds like a perfect solution for your use case. You compose the GraphQL resolver with a chain of Resolver Functions. Your auth check against the document collection table can be implemented as a reusable function.
Take a look at the Pipeline Resolvers tutorial to see if it meets your needs.
I'm using Python and QT (PySide) in a local application (which connect to a database on cloud Azure).
Now, my objective is moving this app on the web, in particular on Azure (I have an Azure subscription), simply transfering it on Azure, it's possible in some manner? I have not found examples on the web.
The important question is: is Python QT (app web) compatible with Azure?
Thanks
UPDATED ANSWER!
Yes, now you can. Well sort of. The mad mads at Digia have created something called "QT for Web Assembly" that can compile your whole app into something that runs embedded into a web page.
https://doc.qt.io/qtcreator/creator-setup-webassembly.html
You might have to rethink connecting directly to the database however, as thats simply not gonna fly with web-sockets (And honestly direct app to remote RDBMS has never been a smart move. Theres a LOT of things that can go wrong letting the internet connnect to your databaes). But you could at least keep the UI and rewrite the databaes layer to interogate something like a GraphQL (or whatever) front end to the data.
OLD ANSWER
I'm afraid your up for a nearly complete rewrite. QT is a desktop/mobile platform. It doesn't go anywhere near HTML/CSS except perhaps for displaying them in a webview component. Azure or AWS won't magically make it into a web application for you.
Your code as it stands needd to be rewritten in a web-first transactional manner. That is it takes a request, processes it, produces a result. To some extent websockets has changed this dynamic for a limited subset of use cases where interaction needs to be non transactional, and modern web app design hides much of the transactionality behind a web-services model, but 90% of web work is still very much transactional.
Database <---> Web server/Web app stack <--- Internet! --> Web browser
My suggestion is to pick up Django (or one of the other systems. If its just simple, Flask is another good alternative. Flask for simple apps, Django for the big stuff. Or use something else, you have choices here!, and start from scratch. Analyse your products function and start mapping out how to make this work as a database driven transactional system.
Theres no shortcuts here, I'm afraid.
I have been searching a lot for info and examples of the principles of making a simple multi-user web application.
The app i am going to make is used for deadline management and can be described as a simple calendar where users can register events.
I have no problem making this for a single user in PHP or ASP.NET, but how can i make this for multiple users, so they can register and only see their own data.
The app itself is pretty simple, and there will not be many users max. 50-100.
I find it hard to find info about this topic.
My own idea, which probably isn't the right way to do it is:
When a user creates an event, store it in a table with the user's ID.
When selecting data, use the logged in user's ID and get the corresponding event(s).
I would strongly recommend working within a framework in order to avoid re-inventing the wheel. If you know python, consider flask, pylons, or Django. If you would prefer to continue working in PHP (you should avoid working with ASP.NET if you are ever going to work with non-Windows developers) try Drupal. Ruby on RAILs has some options, as well, but I've never used it.
The way you are attempting to implement this is likely to lead to an oversized, overcomplicated database that is very hard for new developers to get used to. If you must implement this yourself, you should have a user/password table, an events table, and a table linking together the two (e.g assigning ownership).