What i am looking at is having a angular microfront-end inside another react microfront-end, is this something we can achieve from single-spa
Yes, this can be done two ways. It depends on the frameworks being used by your applications.
Option 1: Cross microfrontend imports
See the Single-spa documentation on cross microfrontend imports here.
This option is ideal if your applications are using the same framework, and uses the simplicity of normal import statements.
Option 2: Single-spa Parcels
See the Single-spa documentation on Parcels here. This option is ideal if you need to cross-framework support, but Parcels are harder to use and understand so we generally don't recommend using them unless you're sure that's needed.
(As an aside, many people think they need to embed on microfrontend in another, but this isn't always true and you might be able to solve your requirement in a different way; depends on your use case).
Related
Word.CustomXmlPart is still in preview and not recommended to use (link) but I can use Office.CustomXmlParts to store any data (link). I don't find any documentation around difference between these two. What basically is difference between these two and what should I use ?
They do essentially the same things. The Word-specific APIs perform much better because they use batching of commands, whereas the Common APIs make a round trip between the add-in and the document with every command. For that reason, we recommend that when the Word-specific APIs are released, you use them. Until then, for production add-ins, use the Common APIs (Office.CustomXmlParts).
I have seen this question What is the difference between a class library and a framework
and throughout all the provided answers, the framework is always referenced as a framework. I am looking to get more technical. What exactly is a framework? A class of classes that control all functionality and provide ultimate abstraction and the ability to customize it? I am just looking to understand what exactly a framework is, as far as initializing it, not just what it accomplishes, but how exactly it is implemented. How I believe it's used/implemented is listed below.
variable = Framework() -> Reference the variable
Framework is an infrastructure, ready-made and predefined, with some particular rules of the game on the "development field", according to which, you can build your application, on top of it, by "playing with framework rules" (you can, at some extent, customize those rules).
Spring MVC is a good example of Framework. You don't control how the View Resolving, Dispatching or Template Rendering happen and achieve a goal together.
Think of this as a big machine, where you can plug in and integrate your components which are applicable to that machine.
Library, on the other hand, is just a set of classes, which provide already implemented functionality out of the box, in order to not start inventing the bicycle again and again.
Apache Commons is a good example of the Library. It has a lot of ready tools and functionality to facilitate your work with String objects.
Think of this as a set of instruments and tools, using which, you can build your own machine.
With respect to how it is implemented question. This is like asking how the Boeing A220 is built?. I'm not sure anyone can describe here how the Framework is implemented in the details. But if I understood uour point about whether the Framework is used via classes, then:
Framework might provide some classes as an abstraction, yes, but it's not about them, it's more about mechanics of the entire system. The main thing it provides is the mechanism and mechanics of how the system is designed to work.
I see that Go itself has a package net/http, which is adequate at providing everything you need to get your own REST APIs up and running. However, there are a variety of frameworks; the most popular maybe say gorilla.
Considering that one of the main things I need to do going forward is to build REST APIs that will access some back-end storage (databases, caches, etc.) to perform CRUD operation, is it good to go with Go's standard library itself, or should I consider using some frameworks?
Normally, people write a new library or framework which solves the problem present in the existing library. But a lot of the frameworks also tend to make things worse when actual demands are simple.
So I have few questions:
Is the basic library in go lang good enough to support basic to moderate functionality for REST?
If I do end up using the inbuilt library and tomorrow have to change it to use some framework (like a gorilla), how difficult/costly would that be?
Are frameworks really addressing the problems or just making simple problems complex?
I would be extremely grateful for someone to share his thoughts here (who has been through making this choice himself) while I research more of my own.
The net/http package is probably sufficient for most scenarios, but if you want to ease your development, you should use a third-party package, such as Gorilla.
For example, net/http's ServeMux does a great job at routing incoming requests for fixed URL paths but for pretty paths which use variables, you will need to implement a custom multiplexer while using Gorilla, you are getting this for free.
Another example is if you want to specify RESTful resources with
proper HTTP methods, it is hard to work with the standard
http.ServeMux, while with Gorilla's mux package,
requests can be matched based on URL host, path, path prefix,
schemes, header and query values, and HTTP methods.
One of the great benefits of Gorilla is that it is fully compatible with the net/http package and can be substituted in the future.
See 1.
I totally encourage you to use Gorilla's toolkit to develop REST services.
The built-in net/http package is sufficient to build a complete REST API. However, some of the libraries can make building an API slightly easier, particularly if the REST API is complex. Changing from the built-in facilities to any decent framework is relatively straightforward - they generally accept handlers of the http.Handler type.
In the end, though, this is an extremely situational choice. The best thing you can do is examine each available solution, contrast and compare, and build a proof of concept with the top options if you possibly can. First-hand experience will guide you best.
I have already done all the I18N and GetText things in multiple languages for an existing site.
For selecting one language or another it seems that prefixing urls with path parts like www.domain.com/fr_FR/my_action or www.domain.com/de_DE/my_action is the best way to go, gor Google friendly sites.
I have found this module: Catalyst-Plugin-I18N-PathPrefix And seems to be based on this advent article
Is it the right way (or current best practice) to do this in Catalyst?
It promises that I do not need to change my actions, my required arguments and urls.
Or this plugin/technique makes a overload in the server that I can better avoid rewriting all my urls by hand?
Regards:
Migue
Are www.domain.com/fr_FR/my_action and www.domain.com/de_DE/my_action the same resource, just represented in
different languages? Or would your users see different contents depending on the language they choose (like, I don't know, different news)?
If the answer to the first question is yes I'd rather go for implementing Accept-language header compliance, for example using I18N::AcceptLanguage, which has the additional benefit that it won't interfere in any way with how you designed your URLs.
I take the risks and implemented the Catalyst-Plugin-I18N-PathPrefix plugin. It was easy, and the server load (that was my main concern) seems to be unnoticeable.
Lets say... I should use time to optimize a lot of things of my own code before be concerned about the plugin performance.
Thank you, anyway.
I'm using C++, but I think that my question goes beyond a single programming language.
What is better - use framework's classes or separate libraries. For example, if I'm using Qt in some project is it better to use QHttp or use cURL (QtXml or TinyXML etc.)?
From my point of view using framework's classes has following features:
Better compatibility with other framework's classes (for example, GUI)
Less dependences
But from other hand separate library could provide better functionality.
What do you think about it?
I get nervous about too much 'framework,' as at some point it can become impossible to extract your code from the 'framework'.
Using different libraries from one 'framework' is fine, but I'd hide them behind my own abstractions rather than routing 'their' types through my core code.
At my company, it depends on the needs of the project. Generally we prefer to use the framework classes. But if it seems that we will have write a lot of extensions or helper classes, then we look for separate libraries.
I tend to go for "what provides the best functionality?". I'll use a framework's methods mostly by default unless it doesn't provide something I need. Then I'll be tempted to use a third party library. If I'm using a lot of third party libraries, I might question the need to use the framework. If I'm using third party libraries I can't live without and they conflict with the framework, the framework goes, unless I can't live without it. It really depends on the situation. Is it the framework I need to accomplish my task, or the third party librar(y|ies) implementing the functionality? Inclusion is then prioritised as appropriate.
It's the job of the framework author to lock you in. It's the job of the application writer not to get locked in.