I am exploring different options to for using openstack horizon.
Use existing horizon app and add new dashboard and apps to it
Start web application from scratch and use openstack APIs and Reactjs for frontend.
Which option shall we select and if we go with option 2 then is there any way we can use existing horizon app modules in our application? I am also open for any other option which you guys can suggest to explore.
Note: I am newbie at it so please let me know how i can improvise also.
Ultimately, it depends if you want the user interface to be part of your OpenStack / Horizon dashboard or now.
If you do, then there is only one choice. Build it as Horizon plugin. End of story.
If you don't, then you need to make a judgment as to whether using Horizon as a framework for your user interface is going to be advantageous or not.
On the plus side, Horizon provides lot of infrastructure for implementing plugins, a panel structure, modal dialogs and so on. It also has some nice stuff for integrating Openstack auth into Django.
On the minus side, Horizon is complicated and not well documented. The learning curve is significant. You will also need to do some work to remove or disable panels, etc that Horizon provides by default. You may find that aspects of the Horizon are hard to modify ... if they are not suitable for your UI design.
Finally, you need to consider the long-term maintainability of an (in effect) fork of the Horizon codebase. What happens when (say) Django 1.x is end-of-life and you are stuck with a version of Horizon that has diverged from mainline Horizon.
My gut feeling (based on experience with Horizon plugins) is that you would probably be better off NOT using Horizon in this case. Build it from scratch using Django or Reactjs or something else.
Related
I am looking for way to create simple multiuser Dashboard for OpenStack as alternative to Horizon. Idea is keep Horizon for administrators and manage users in another aplication with possibility to create (with admin confirmation) custom system.
My idea is create a web aplication (Node.js) which would communicate with OpenStack REST API because we need some extra feature (messaging, LDAP/AC Auth).
I also looked for some projects like alternative to Horizon, but cant find anything .
My question is, what is better idea? Create custom solution or use some already created Dashboard(which one?) and only modify it?
Take a look at this open source project:
https://github.com/cyverse/atmosphere
https://github.com/cyverse/troposphere
So its frontend is based on ReactJS and BackboneJS and the backend is the Django and DRF which consumes the OS python client API.
As for your question, it depends. The horizon project has a very good plugin registration service that let you easily create custom dashboards and you don't have to worry about many other details.
However, create a new dashboard on your own also sounds cool but it needs a lot more effort and time than using the horizon.
HTH
I want to design and architect a scalable app that will be a combination of a social blog with all admin and blogging features plus the app will also have course broadcasting like coursera and udemy.
What technologies should I look into:
I have studied some LAMP and MEAN stack based apps but got more confused in choosing the tech stack.
should I use a standard solution like BuddyPress or some other WordPress based stuff or should I design it from scratch?
How do I divide it component wise so that's it scalable and highly modular?
Are there any references or some pre-made solutions or documentations or design patterns because whatever I am planning to work has already been done.
It depends on what do you wanna achieve.
For example, you have these ways for architecture:
A whole APP in one server.
Microservices, distributed parts of your app.
Serverless (Backend as service).
About apps, you already said it:
If you choose to create something from scratch, you can control the architecture and services that your app need in order to work at 100%.
If you choose APPs like Wordpress, Vanilla Forums and similar (APPs that you will have to install that you didn't create and perhaps you will end creating modules that solve problems that you have).
What else?
Do you have time to create something from scratch?
Do you have the money to create something from scratch?
Does premade software like Wordpress fulfill all your requirements?
To be honest, if you have the money and time you can choose whatever you want.
But if time is important, well, choose something premade like Wordpress and similar solutions.
Once you answer those questions we will be able to help you with more details.
I was looking at some larger scale Meteor applications and was wondering why some of the initial sites do not seem to use meteor.
As an example when you go to classcraft and look at the main website you notice it is not using meteor.
Then when you go to their actual application (click signup for example) you can see it uses Meteor.
So they make a clear separation in terms of technology. Can someone explain the reasons? Is it not as efficient / clean to just use Meteor for the whole thing.
Thanks,
Jean
Each company makes their own decisions on how/when/where to use technologies. In the case of meteor, the really strong part of meteor is that it's real-time updating. That means things like messaging systems, getting updates out quickly, etc. good uses for meteor.
It appears as though classcraft has decided they don't need that capability on the home page. There's also some concerns with SEO and meteor that perhaps classcraft didn't want to deal with.
Finally the home page not being built in meteor shields the DB from public view, which is not a huge security advantage, but may be one they considered.
This is all me finding reasons for them as I don't know why they'd make that decision. I don't make that decision for my sites/apps but that doesn't mean others might not see things differently.
I'm the founder of Classcraft. To answer your question, it's because we didn't need everything Meteor had to offer for the front-facing website : reactivity, flexible templates, a database, etc. Meteor is amazing for building apps, but it's overkill for a static website. Also, if the front-facing website was built within the game app, it'd mean that any copy changes or tweaks to the front-facing would cause us to have to redeploy the app, which means some downtime (not much, but still) for our users. Keeping them separate also allows marketing people (who aren't developers) to tinker with it without going into the code base for the game.
We decided to build the front-facing website using middleman. Middleman allows you to generate a precompiled static website, which allows for amazing speed and simple server configuration (it's served from S3, which means it's super fast).
I'm sure the reasons are different for everybody, but that's what it was for us.
Shawn
I am evaluating Meteor as an alternative to developing real-time capabilities using socket.io and it looks like awesome framework for single page real-time apps. It is great time saver that enables developer focusing on the business logic of the app, rather than writing boilerplate code. However, I find it still pre-mature for a medium size app with multiple pages/routings and REST api. Plus, number of features like i18n are still not available which requires some time investment to develop by myself.
I think that it would be great if I could combine Meteor and Express and use Meteor in use cases where it really shines.
Is it possible to develop an app using standard Express/Mongo stack and use Meteor for only specific part of the app where I need real time collaboration?
For example, can I share a session between Express/Connect and Meteor?
Thanks!
This does not directly answer your question, but I thought I'd throw it out there:
You should check out the community packages on atmosphere. Specifically, I'd recommend having a look at iron-router and i18n (I'll note I have not used the latter).
I've built a large production app that uses iron-router and it's running smoothly. You may also be able to use its server-side-routing capabilities to implement your REST api.
There is the requirement, to write a portal like ASP.NET based web application.
There should be a lightweigted central application, which implements the primary navigation and the authentication. The design is achieved by masterpages.
Then there are several more or less independent applications(old and new ones!!), which should easily and independent be integrated into this central application (which should be the entry point of these applications).
Which ways, architectures, patterns, techniques and possibilities can help and support to achieve these aims? For example makes it sense to run the (sub)applications in an iframe?
Are there (lightweighted and easy to learn) portal frameworks, which can be used (not big things like "DOTNETNUKE")?
Many thanks in advance for you hints, tips and help!
DON'T REINVENT THE WHEEL! The thing about DotNetNuke is that it can be as big or as small as you make it. If you use it properly, you will find that you can limit it to what you need. Don't put yourself through the same pain that others have already put themselves through. Unless of course you are only interested in learning from your pain.
I'm not saying that DNN is the right one for you. It may not be, but do spend the time to investigate a number of open source portals before you decide to write your own one. The features that you describe will take 1000s of hours to develop and test if you write them all from scratch.
#Michael Shimmins makes some good suggests about what to use to implement a portal app with some of the newer technology and best practice patterns. I would say, yes these are very good recommendations, but I would encourage you to either find someone who has already done it this way or start a new open source project on codeplex and get other to help you.
Daniel Dyson makes a fine point, but if you really want to implement it your self (there may be a reason), I would consider the following components:
MVC 2.0
Inversion of Control/Dependency Injection (StructureMap for instance)
Managed Extensibility Framework
NHibernate (either directly or through a library such as Sh#rp or Spring.NET
A service bus (NServiceBus for instance).
This combination gives you flexible user interface through MVC, which can be easily be added to via plugins (exposed and consumed via MEF), a standard data access library (NHibernate) which can be easily configured by the individual plugins to connect to specific databases, an ability to publish events and 'pick them up' by components composed at runtime (NServiceBus).
Using IoC and DI you can pass around interfaces which are resolved at runtime based on your required configuration. MEF gives you the flexibility of defining 'what' each plugin can do, and then leave it up to the plugins to do so, whilst your central application controls cross cutting concerns such as authentication, logging etc.