I've been searching around for a while on this, but as of yet haven't found anyone else trying it. So I'm asking for feedback and critique - both on if this seems reasonable, and if there's a better established pattern for it.
Basically, I want to be able to easily publish a "demo" version of a react/redux app. My specific example is an app I built but that is only useable with our internal database with user information. I can't show that anywhere, because we don't want the information to escape out into the world.
Since all of the model interactions are routed through redux, it occurred to me that I could drop in a new set of actions based upon the URL.
Say the user goes to myawesomeapp.com - they're given the full app, login prompts, security, access to the database.
But an outside party could go to demo.myawesomeapp.com (for example), and get an app that is functionally the same but is wired up to dummy data that isn't saved.
The general pattern that I have would be this:
Vaguely, in actions/index.js
export * from './common_actions';
if (location.href.match(/demo\.myawesomeapp\.com/)) {
export * from './demo_actions';
}
else {
export * from './actions';
}
I don't really like that - it feels brittle and like a hack. But it works! Registered users can use the actual app, and demo users can try it out in a sandbox.
Judicious use of exported constants and values also allow peppering of other flags and data - overlays of text to walk through things, links to sign up for the actual app, etc.
I love this as a concept - with just a few new redux actions, you get a fully sandboxed app to show off with no worry of cross contamination. It's much easier than trying to sanitize all the endpoints.
And even if an action wasn't properly isolated in this manner, the worst that would happen is that they'd get an access denied error from the actual backend since they're not logged in.
But to the world, my questions are -
1) Does this seem like a reasonable thing to do or are there gotchas I'm not considering it?
2) Does this seem like a reasonable way to implement it, or is there a better approach I haven't considered?
I don't like this solution, if i understood you correctly this solution will duplicate your code, which is never a good idea, you'll have to change two different code bases with every little change, needless to say it will duplicate your work, why not just point the demo app to a different database ? or better yet(and it's also industry standard) create a "time trial" role for your users so they can test your app and if they like it, they already have an user account.
Related
I'm struggling to find the right words to convey what I'm looking for in my research, so I thought I would ask the stackoverflow community. I am looking for best practices to create records in different tables at once.
An example would be, user registration. Say you need to create 6 records for that user when they sign up, which need to connect. By connect I mean in the sense that if a user and team were created on user registration, the userID would need to be included in the team's members array. So the records need to fire in order so the relationship is properly recorded. So user would need to be created first, then the team record so I can add the userID to the team's members. Also note that the user record would need to be updated later on (after the team's record is created) with the teamID under the user's teams.
So as you can see it feels a bit all over the place. Currently I have multiple API calls being fired on user submit. While I have this working using redux, firebase and react — I foresee a lot of potential errors happening and feel as if I am not doing this in the most efficient way. I want to do this correctly and happy to do the research, I'm just not exactly sure what I am looking for. I was hoping for some guides, information, search terms, etc — basically anything to help me understand this concept more throughly if that makes sense.
This is a perfect candidate for GraphQL and a backend that handles it properly. Take KeystoneJS for example. You could do a single create user and handle it all internally via the hooks system. You can also do nested creates / connects all in one mutation and KeystoneJS will take care of all of it for you if there are nested operations. For example you can create object A, then create object B in one mutation. It'll create B, then A, then connect A to B... with no extra work on your end. I just give this as a single example of a tool you can use. Here is an example mutation that Keystone just handles:
mutation CreateUser {
createUser(data: {
username: "test"
organization: {create: {
title: "test"
}}
})
}
Notice organization is created inside of the user mutation.
Yes, I think the best practice is to have your back end, whatever it is, do the work. It will fail if it bumps into an issue and clean itself up. Otherwise, it produces a positive response. I hope this is helpful...
For alternatives, since this is a pretty open ended question... I've also created a nestJS back end. That works great too, but it's a lot less opinionated with fewer built in solutions, so you do a lot more work (but it's more flexible). Any CMS should give you control over this (Strapi seems to be taking off... I just ran into too many bugs with it).
I need to create a pretty complex website for my class and before I started, I wanted to get some input from more experienced coders if I'm on the right track.
Basically, when I go to the url: I get a simple login page, when a user logs in - he can view his profile and make schedules / save etc...
I read a bit online and this is how I decided to proceed (please let me know if there is a simpler way or an already-made code for these):
1 . Access phpmyAdmin - create db
2 . Create a php function to access the db (add users etc...)
3 . use a login form with a php function on the main page and authenticate user/pass by accessing the db
4 . Use cookies to keep user logged in.
I also need to keep several lists for each user like:
classes = (comp232 , comp348 , comp352.....)
Which is the best way to do this for each user:
DB, txt file, List, Arrays?
The answer is 'depends'. However, when you had mentioned that you want to develop a 'complex website', it deserves to have Database roundtrip :) whereas all the other options you had mentioned would be simple enough for a stand alone application.
To answer your other main question, yes, there are already built in solutions which you can make use of, if you don't want to write the application on your own. However, you may need to evaluate thoroughly whether it fits your bill, else you may end up customising the application which is more or less half writing of the application by yourself.
If you want to write the application by your own, the PHP has got a built in APIs to achieve whatever you had mentioned. We have a great set of forums to get assistance wherever we are stuck.
Thanks in advance for any help offered and patience for my current web-coding experience.
Background:
I'm currently attempting to develop an web based application for my family's business. There is a current version of this system I have developed in C#, however I want to get the system web-based and in the process learn cakephp and the MVC pattern.
Current problem:
I'm currently stuck in a controller that's supposed to take care of a PurchaseTicket. This ticket will have an associated customer, line items, totals etc. I've been trying to develop a basic 'add()' function to the controller however I'm having trouble with the following:
I'm creating a view with everything on it: a button for searching customer, a button to add line items, and a save button. Since I'm used to developing desktop applications, I'm thinking that I might be trying to transfer the same logic to web-based. Is this something that would be recommended or do'able?
I'm running into basic problems like 'searching customer'. From the New Ticket page I'm redirecting to the customer controller, searching and then putting result in session variable or posting it back, but as I continue my process with the rest of the required information, I'm ending up with a bit of "spaghetti" code. Should I do a multi part form? If I do I break the visual design of the application.
Right now I ended up instantiating my PurchaseTicket model and putting it in a session variable. I did this to save intermediate data however I'm not sure if instantiating a Model is conforming to cakephp standards or MVC pattern.
I apologize for the length, this is my first post as a member.
Thanks!
Welcome to Stack Overflow!
So it sounds like there's a few questions, all with pretty open-ended answers. I don't know if this will end up an answer as such, but it's more information than I could put in a comment, so here I go:
First and foremost, if you haven't already, I'd recommend doing the CakePHP Blog Tutorial to get familiar with Cake, before diving straight into a conversion of your existing desktop app.
Second, get familiar with CakePHP's bake console. It will save you a LOT of time if you use it to get started on the web version of your app.
I can't stress how important it is to get a decent grasp of MVC and CakePHP on a small project before trying to tackle something substantial.
Third, the UI for web apps is definitely different to desktop apps. In the case of CakePHP, nothing is 'running' permanently on the server. The entire CakePHP framework gets instantiated, and dies, with every single page request to the server. That can be a tricky concept when transitioning from desktop apps, where everything is stored in memory, and instances of objects can exist for as long as you want them to. With desktop apps, it's easier to have a user go and do another task (like searching for a customer), and then send the result back to the calling object, the instance of which will still exist. As you've found out, if you try and mimic this functionality in a web app by storing too much information in sessions, you'll quickly end up with spaghetti code.
You can use AJAX (google it if you don't already know about it) to update parts of a page only, and get a more streamlined UI, which it sounds like something you'll be needing to do. To get a general idea of the possibilities, you might want to take a look at Bamboo Invoice. It's not built with CakePHP, but it's built with CodeIgniter, which is another open source PHP MVC framework. It sounds like Bamboo Invoice has quite a few similar functionalities to what you're describing (an Invoice has line items, totals, a customer, etc), so it might help you to get an idea of how you should structure your interface - and if you want to dig into the source code, how you can achieve some of the things you want to do.
Bamboo Invoice uses Ajax to give the app a feel of 'one view with everything on it', which it sounds like you want.
Fourth, regarding the specific case of your Customer Search situation, storing stuff in a session variable probably isn't the way to go. You may well want to use an autocomplete field, which sends an Ajax request to server after each time a character is entered in the field, and displays the list list of suggestions / matching customers that the server sends back. See an example here: http://jqueryui.com/autocomplete/. Implementing an autocomplete isn't totally straight forward, but there should be plenty of examples and tutorials all over the web.
Lastly, I obviously don't know what your business does, but have you looked into existing software that might work for you, before building your own? There's a lot of great, flexible web-based solutions, at very reasonable prices, for a LOT of the common tasks that businesses have. There might be something that gives you great results for much less time and money than it costs to build your own solution.
Either way, good luck, and enjoy CakePHP!
When I try to create some entities I don't see the option to input fields. I just see the SaveEntity button.
However I can view all the existing entities.
What is very strange is - there is another entity called VideoEntity for which the create did not work yesterday but works today.
Can somebody help me with this seemingly unpredictable tool ?
Regards,
Sathya
i think the console knows what properties each entity has based on existing data, rather then your models. and the data is only updated periodically. when did you upload your app? maybe waiting a few hours will give the console time to update.
alternatively, you could use the remote api to add your entities, or write a small snippet and upload such as ...
VideoStatsEntity(app='home', ip='116.89.52.67', params='tag=20130210').put()
Writing a simple interface to the data-store to allow you to edit/create models is probably the best thing to do in this case. You know what they contain so you can adjust your interface accordingly, rather then waiting for the admin interface to "catch up" as Gwyn notes.
I believe that there are some property types that are impossible to add via the admin interface that you are using so you'll probably get to the point sooner rather then later of creating a custom interface.
The admin datastore view is good for quickly checking out the contents of the datastore, but ever tried paging through 100's of entries? Not fun.
I am building an GAE app that allows users to share documents over different contexts. Nothing too fancy.
I want to use Gdata in such a way that it is the app that owns the documents, and not the users. This way, I shouldn't need any kind of tokens --one would think.
This is the main idea:
App user creates doc --> App creates doc and owns it --> user can RUD & share the doc
Is there any recommended way to authenticate using just a hard coded user & password?
The ClientLogin, up to now, seems to be the way to go.
http://code.google.com/apis/gdata/docs/auth/clientlogin.html
But I still have some doubts about the following:
Am I putting myself in a scenario of possible restrictions over other alternatives?
Is really ClientLogin the best way to go?
Could really use advice from others' experience here. Procrastination is killing me.
Cheers,
A.
If this is a personal project, and you've only got a very small group of users, the design might be OK.
One really good reason to use OAuth is that you won't need to store the account password somewhere. Instead you'll be able to implement a simple 'setup' process to get and store an access token. OAuth is also nice since you'll be able to restrict the access scope.
However, I must say, I find your question very vague -- so more specific answers are difficult.