Suppose I have the following situation: We have a SPA containing many sub applications, with for example the following functions:
See news
Create products (upload a picture, set product info, etc)
Check invoices
Etc.
with the following directory structure (structure inspired by the book 'Marionette Gentle Introduction'):
-- Assets/
---- js/
------ app.js
------ apps/
-------- header/
-------- news/
-------- productcreate/
-------- invoice
The header contiains menu entries to all these sub-apps. Suppose that 'productcreate' is a very large (as in: lot of tasks) sub-application.
Question
I want to use this 'productcreate' sub-application both as a part of this larger application (really 'in' the application, with header above it etc) but also in a standalone setting. What would be the best way to approach this?
Would I for example need to develop these applications (the larger one and the productcreate one) seperately and is there a way to load an 'application in an application'?
start with developing "productcreate" as a widget/app/whatever which can run stand-alone. and use that in main application when needed. Make sure sub-app and app follow pub-sub pattern, so that mainApp respond to sub-app events, if it is available, else nothing breaks. If you use requirejs loader, you can share common dependencies btw apps, and still load it only once.
Related
I have 2 existing projects that are independent of each other, and I was tasked to bring them together under a suite of some sort and share some small data between them. The problem is one platform is using ReactJs and the other using VueJs.
Example:
To give you a small example, it's like having Facebook and Instagram using different JS frameworks, and bringing them together under one platform let's call it Meta so the user goes to one platform and finds all products that the company offers.
(Example of the data that needs to be shared: Dark/Light Mode, User is logged, ....)
And is it possible to wrap both apps inside another, like having a whole new project consisting of a Navbar and a body, and the body switches between showing the first and the second platform using the navbar links?
Please if you have any suggestions throw them at me.
I'm building a static website hosting and would like to generate default web pages for my users and would like to use Hugo for this. Question is, what would be the best way to dynamically generate web pages for multiple users? This is my thought so far:
User fills up form for their website content e.g., photos, title, product descriptions, etc.
Pass to backend (I'm using Perl's Mojolicious) and create markdown files based on the provided information and save them in a designated folder created for this user
Run Hugo to build using those md files and move the public folder to user's root directory
This doesn't look right to me as there will be contention of multiple users to run Hugo and I'm thinking that it is much easier if I can just create the html files directly from backend instead of creating md files and then run Hugo to create the html files. Is there any better and smarter way?
If I am not mistaken, it seems you want to make a WordPress portal alike or something similar, going from Markdown plus theme down to HTMl/CSS/JavaScript content. The end-users edit the content in Markdown, choose the theme and the rest will be taken care of.
IMHO, there might be two ways:
(1) Using Hugo at the back-end and taking care of the destination folders and generated artifacts as well as mapping generated links to the front-end corresponding to your particular end-user's hosting. You can create a Hugo wrapper in which the input will be fed to Hugo and the generated pages will be in the public folder. In this way, you have to rely on an external tool (read Hugo) and wish for a long-term support version like many other systems (e.g. Ubuntu, Java, Windows).
(2) Creating a similar generator like Hugo or another (c.f. StaticGen for more generators on different languages). You may need the core of a Markdown based static site generator, for instance, a Markdown parser, link translators and generators, etc. With extra effort, you might have more control of every smaller component/library that you use, can configure the generated artifacts, their destinations, etc.
A side note: Markdown is a not-so-bad choice for content. Even WordPress have offered support for Markdown. Nonetheless, Markdown itself is not standardized but rather de facto. There are so many flavours. You might want to look up to or stick with a good one, for example, CommonMark.
Hi I need your help trying to figure it out something.
First a little background, I was used to code in Django, it was fast to code and good, but times change and Node is taking over most of new apps, then I move to Express a couple of years ago, however I still miss a lot of the Django functionality, then I start coding a little library to help me with common tasks, then start growing until the current point where you have a core library and plug-able “apps” to do recurrent tasks, like notifications, auth and more, or at least that’s the plan.
Right now an app works something like this:
./controllers (All renders)
./endpoints (Restfull API endpoints)
./models (Static and DB models)
./public (Public files)
./style (Scss styles with bootstrap injected)
./views (Default templates, distributed with the app as example, loaded by default)
…/…/views (Custom views to rewrite the default ones from the app)
On start, JSloth compile everything for you and run the server (hot reload included):
Now, that works fine using an static multipage environment, but I will love to use Angular for that, changes will be needed but I want you guys to lead me in the right direction.
So far I have 2 ideas:
1- Split Routes/Html apps and Restful/Endpoints, then basically use an standard set up on that kind of apps with webpack and AngularSSR.
The big downside is, you can’t give an out the box frontend implementation for apps.
2- Figure it out a way to provide an Angular app for each JSloth app, in this way if you install/copy the auth app you will be provided of user lists, interfaces to update your profile, etc.
I’m thinking that may be a problem talking about performance because in this way you will have a lot of Angular apps, am I wrong?
I need a easy way to allow the final user to share footers and headers at least, maybe even styles or scss variables for colors, in that way it will not look like a huge change.
Do you have any other option? Any better idea?
Thank you so much for the help, this is the repository: https://github.com/chrissmejia/JSloth
Edit 1: Forgot to add the models folder
I'm developing a web-application with angular and this will be used for different customers. Each customer has his own needs (specific functionality) and style (css). A lot of the functionality is shared though.
What I'm looking for is a total solution to keep this project clean and maintainable. The code will be running on the local server of each customer and the customers shouldn't see the specific code for the other customers (with other words, something like grunt should have filtered the deployment).
What I had in mind:
Define different tasks in grunt to watch, build, etc per customer
Define parent controllers (~inheritance) and parent views to share functionality
Use a subfolder for each customer
e.g. views:
app/views/general/home.html (loads main.tpl.html)
app/views/customer1/main.tpl.html
app/views/customer2/main.tpl.html
e.g. controllers:
app/scripts/controllers/general/...
app/scripts/controllers/customer1/... (extends general controllers)
e.g. css
app/styles/general/...
app/styles/customer1/...
Grunt will select only the files relevant for the customer and should remove the customer-related paths. (e.g. both app/views/customer1/ and app/views/customer2/ should go to app/views/customer, which is loaded by app/views/general/home.html)
A big disadvantage will be that the app/views/general/home.html will have a reference to unexisting file while developing. The same goes for index.html where I need to include the controllers from the target dist folder, not from the project folder structure (while developing). Which makes everything a bit less readable and logical.
Do you think this is a good approach? Are there optimizations or alternatives coming to mind? Do you know of any grunt modules or angular modules aiding for such set-up?
Thanks in advance!
One approach you could use is to run a basic node server that will store and serve up, using a rest call, the user preferences. So you would save user specific settings such as layout, etc and update these in a simple JSON file stored on a local or remote node server.
Searching for ways to build REST APIs, I found skue (https://code.google.com/p/skue/). However there is not much information on the site. My plan is to build a rest api as follows strictly:
Models << Business logics << Restful Resources.
What this means is: the models are access exclusively by the business logic; the restful resources interface is the only layer a client has direct access to. I am specifying all this to avoid people suggesting using the appengine-rest-server.
My question is: has anyone ever successfully used Skue? If so do you have any examples you would not mind sharing? GET and POST would be sufficient, but more is welcomed. If not Skue, are there any frameworks out there that allow building such rest-apis on top of the google-app-engine?
I'm the author of Skuë. Skuë means "mouse" in Bribrí which is the language of an indigenous group of people of Costa Rica, my Country.
I know there isn't enough information on the site: (https://code.google.com/p/skue/)
For developers that want to use it on their own projects. I'm sorry for that I just haven't had the time to do a proper documentation since this is just a side project and not my daily work.
However, I'm willing to help you out with ramping up so you will be able to use it. The first thing to notice is the small example that it's part of the source code. Go to the site then click on Source -> Browse and then expand the "app" branch.
The code inside of the "app" folder represents your own API implementation. The package "skue" contains the actual implementation of the library so basically you just create your Python project for Google App Engine and includes the skuë package directly into it.
Now overwrite your main.py file with the content of the downloaded main.py: main.py on Skuë project.
The most important part of that file is where you put your own routes to your resources implementations: Notice here the use of the "ContactResource".
TASK_HANDLERS = [
]
API_HANDLERS = [
('/contacts/(.*)', ContactResource)
]
API_DOC = [ ('/', ApiDocumentationResource) ]
Browse to the contact resource implementation.
There are a lot of things going on under the hood there.. but the idea is for you to not worry about those.
You need to inherit from the proper Resource parent class depending on the kind of resource you want to create, there are four basic types:
DocumentResource: A document resource is a singular concept that is akin to an object instance or database record.
CollectionResource: A collection resource is a server-managed directory of resources. Clients may propose new resources to be added to a collection. However, it is up to the collection to choose to create a new resource, or not.
StoreResource: A store is a client-managed resource repository. A store resource lets an API client put resources in, get them back out, and decide when to delete them.
ControllerResource: A controller resource models a procedural concept. Controller resources are like exe- cutable functions, with parameters and return values; inputs and outputs.
Like a traditional web application’s use of HTML forms, a REST API relies on controller resources to perform application-specific actions that cannot be logically mapped to one of the standard methods (create, retrieve, update, and delete, also known as CRUD).
Now take a look at the "describe_resource" implementation on ContactResource example. When you inherit from the basic resource types described above the next step is to programmatically describe your resource to the outside world using that method. The underlying Skuë implementation uses that method to validate require parameters and also to self describe the endpoints when you perform an OPTIONS request on them.
And the final step is for you to implement the methods (CRUD) that you want to handle for your resource.
Again with the ContactResource example, that resource handles the creation, update and read of Contact items.
I hope this helps you at least to understand how to start using the library. I will create better tutorials in the future, though.
In the meantime you can contact me via email: greivin.lopez#gmail.com and I will send you a more elaborated example or even something that matches your requirements.
Important Note: Currently the Skuë project only supports responses in JSON format. If you plan to use another format you will need to create the proper classes to handle it.
Greetings from Costa Rica.
I haven't used skue, but what you're looking for sounds like a good fit for Google Cloud Endpoints. See my previous answers on the subject for more details.