I'm looking for a "best practice" kind of answer with regard to Facebook Apps and staging/production environment. Instinctively, I've provided each environment with its own Facebook App, complete with its own ID and secret. It appears (here, here and through extensive Googling) that it's simply not possible to share OG configuration across apps, so I've been copying application settings across environments (icon, requested permissions and texts, etc). It's been a pain and ugly, but I've lived with it.
Alas, with the introduction of opengraph actions, this isn't funny anymore - much more to copy and everything has to go through the approval process. Is there no better way to do this? A coworker suggested we simply share the same app across all environments, but I'm apprehensive about that - it means we'll have to share production secrets with the staging environment (I'm not even talking about localhost development environments), and that we'll need to route Facebook traffic to the correct environment somehow (because one Facebook app means one Page Tab URL).
There has to be a better way... no?
I see there's a feature called "Test Apps" now that seems to fit the bill:
https://developers.facebook.com/docs/apps/test-apps/
Test Apps are like regular apps in that they have their own App ID and independent settings, but they offer a number of advantages for use during pre-production:
...
When creating test apps - the settings are copied from your production app so its simple to spinup new apps which mirror your production app's settings
It's working for me so far.
I asked practically the same question at a breakout session at F8 last year. Creating multiple apps is the best practice. They are aware that it is an inconvenience, especially with the open graph objects and actions. They did however mention the possibility of setting up apps in the future via the API, but I am still waiting for this. Until then, it's a manual process.
Related
I'm entering the world of Shiny Rstudio now. So this is a beginner question
One question I came up with is: how do I search for the Shiny Apps available/created? Are all created Apps available? Is there any way that, once I create my app, I prevent it from being viewed? Or during the creation I "block it"?
From so much searching I found this link via Rstudio's website: http://www.showmeshiny.com/
Would this be the search platform for all apps made?
But in the case of http://www.showmeshiny.com/ it seems that it is necessary to send it via "Submit App".
I am not sure if I understand your questions correctly but I might be able to give you some insights.
Are all created Apps available?
No, some shiny Apps are hosted on private servers or/and are embedded in password-protected websites or Wordpress-pages for example. If you dont have those access rights, then you cannot see those Apps.
How do I search for the Shiny Apps available/created?
There is no way of doing that, except on pages like Showmeshiny, the RStudio Shiny Gallery, this gallery of recent Shiny-Apps or pther similar pages. Those Apps are publicly available and you can submit your own App if you like sharing it. Shinyapps.io is a nice and easy way of deploying your App on a server with a few clicks. But you need at least the standard license to include authentication, otherwise they would be free and open for everyone.
Is there any way that, once I create my app, I prevent it from being
viewed?
I am not quite sure, what you mean. If it should be blocked from being viewed at all, I dont see the reason of building a ShinyApp. If you just want to access it yourself, then there are ways of doing so. Either password-protect it where only you know the password or host it on a local server that only you can access.
Or during the creation I "block it"?
If you create it on your computer and run it, it will run on your computer and only be accessible to yourself, except you explicitly configure it otherwise. So there is no need of "blocking it".
I've made quite a few web services over the years, and all of them had admin pages, which either could only be accessed by users with proper roles or all together different "admin accounts".
In all the cases, I made some scope in the main project, and made sure non authorized users couldn't access the pages, it works fine.
However I always had the urge to completely part the entire feature into another service, or even create a minimal desktop app that would access restricted APIs.
I know its pretty much pointless overhead to do something like that, but in such instances like having two developers working on the main site and admin site, or security demands that there are to be no browser friendly way to access administrative features, or well just for the sake of it, I was wondering if there are any cases that the administrative pages have been separated from the main web service.
Any examples or design patterns on the subject are welcome.
I'm fairly new to both Django and Angular. I recognize this is subjective and there are likely many ways to do it, but I'm wondering what best practices people can recommend for laying out such an application. I'm specifically thinking of the case of rich, SPA with the backend being mostly or entirely a RESTful API server, but then I'd like to have a common approach for any apps that serve significant views from Django. (I haven't done enough to decide if the latter warrants using Angular or may be more trouble than its worth).
Specifically:
What are pros/cons of maintaining the front-end code in a separate directory/repository from the backend versus, say, inside a "static" subdirectory of the Django app? In my case I'm the sole developer for now, which has some impact on this decision, but I can still consider myself separate "teams" of back-end, front-end, designer, etc. in the sense that my workflow will put me in one of these roles at a time.
My setup is basically a development machine, SCM in GitHub, and hosted publicly on WebFaction (shared web hosting). I will down the line want to easily grab projects on different development machines, but the primary workflow is just one dev, one prod installation. That said, I'm interested in best practices in real-world projects as I hope a future job may be working with Django.
ADDED: Another point I'm very unsure about is whether the Angular app should/must be bootstrapped by Django. That is, should the front page be served by Django and injected with any data?
PROS:
Can configure URL paths and even API endpoints that change from dev to production, without any alternate config and without these being hard-coded in front-end.
This is maybe necessary for authentication? Unclear to me having not done this yet...
Allows use of tools like the Django debug toolbar app.
CONS:
Couples the front-end to the back-end. What If I want to swap out the latter? What if I want the front-end to work in a sandbox with mock data?
Seems to strongly favor moving all Angular stuff into the Django app layout. At the same time, I don't like having a mix of Angular partials in one place and Django template(s) in another. I am already resolved not to mix NG and DJ templates, as I don't believe much good will come of this.
I also started as solo developer on Django as BE with AngularJS FE. I've put AngularJS files in static folder and everything is fine.
Cons are definitely that you have FE and BE mixed up in one project, but I think that shouldn't matter since you are solo developer. Even if you decide once to hire additional developer (to split FE and BE work) your work wouldn't have any conflicts since one of you would work totally independent.
One of the pros for me is definitely I did entire login process via Django (templating as well) and once login went fine I served rest of the FE (entire AngularJS part).
For Django REST I've used TastyPie. It's great REST enhancement for Django and easy to set up.
This is not a question about writing a web-app Vs a desktop app. It's a question about allowing a bespoke application to run in a browser though use of a custom plugin, effectively using the browser just as your render-window.
QuakeLive does this - it's a C++ application with some extra code to run through a browser. Unity3D and Torque game engines also provide deployment options to do the same thing.
Personally, I'm a bit dubious about the usefulness of such a system. But I'd welcome other opinions on the reasons why this might or might not be a good idea.
Not sure if there's a proper term for this, please edit my tags if there is!
It depends on the application. My background is in medical imaging, but what I have to say would apply to many information system clients:
Pros:
it gets easier to build REST-based integrations between applications. This type of integrations can be used by admins to build integrated portals. (So case ID's from one application can be used to launch another with the right context etc).
ideally, users can install your application themselves, on-demand (depends on context if this is really possible)
Deployment of new versions gets easier. Usually the hosting technology has deployment built-in. In client server environments, this can save a lot of work for the IT department.
You can have a single start URL for PC's and thin web clients (like phones). This makes it easy for users to find your application.
You can centralize configuration for clients. For standalone clients, you could of course centralize configuration somehow, but if you app is web based, you always know for sure there is a server, so you can always use it.
you can offload work that's ineficcient to do locally to the server. (reduce # of roundtrips between client/server).
Cons:
Each browser vendor has its own model of wrapping the native code. There are not too many, but it's definetly extra work.
Your app has to "play nice" with the hosting application. Like when the user closes the browser window, the browser may have prescribed when and how you can ask the user to save.
updates to browsers can break your plugin.
system admins may have restricted installation of plugins, disallowing users to install your application on demand (this happens a lot for activex).
your users may not like that extra code is injected into the browser (there is a lot of malware around that does this)
you don't have the opportunity to update prerequisites before installation
I don't believe really that it's just wrapping existing code in a plugin framework.
Your application won't work anymore when the server is down...
I was hoping to get some suggestions on some best approaches to develop a multi tenant Django project on Google AppEngine.
Some Thoughts to Consider.
I would assume using djnago.contrib.sites is a must.
I would like to use existing applications such as django-profiles and django-registration, I know their models would need porting.
Can multiple domains be pointed to the GAE App and the site be automatically chosen from the request headers?
IF not multiple domains, is there a way to say take a request say to www.example.com/tenantA/login and www.example.com/tenantB/login and push them to one view but with knowledge tennant without changing all the views, maybe using custom managers to hide the complexity from the views.
Generally hoping this will be a discussion of any approaches you have taken in the past or plan to take.
Looking forward to any Comments/Answers.
Regards
Mark
I can answer the App Engine questions for you, though I don't know the Django ones:
Yes, anyone can point a domain to your app using Google Apps, with the 'add services' option, entering your App ID when prompted. You can then check the 'Host' header to determine what site you want to use.
You can hide information per-tenant by using hooks to automatically insert the host in entities and queries: http://code.google.com/appengine/articles/hooks.html
Today Google released SDK 1.3.6, which includes multi-tenancy baked right into the solution.
http://googleappengine.blogspot.com/2010/08/multi-tenancy-support-high-performance_17.html