Today I faced strange GIT error while running GIT pull command.
error: cannot lock ref 'refs/remotes/origin/Feature/Performance_Fix': is at 121133f24b3eda9c7167c7be2b0f31d282b0bbb2 but expected 58840e344e3d301761c726e4f833b83f6b261ecb
Solution :
Run below commands to fix this issue (Update the object name stored in a ref safely, used this to delete the reference)
git update-ref -d refs/remotes/origin/Feature/Performance_Fix
git pull
I was trying to use Date property of DateTime field in LINQ query but got this error.
Message = "The specified type member 'Date' is not supported in LINQ to Entities. Only initializers, entity members, and entity navigation properties are supported."
Example query :
var query = from employeeRecord in _context.EmployeeRecord
where (employeeRecord.StartDate.Date== currentDate)
Solution : Use DbFunctions.TruncateTime to truncate time part from a DateTime.
Updated Query :
var query = from employeeRecord in _context.EmployeeRecord
where (DbFunctions.TruncateTime(employeeRecord.StartDate) == currentDate)
After adding new bean to project I got below error during startup
13:44:19:254 ---> System.InvalidOperationException: Can't use schemaId "$Employee" for type "$staff.Employee". The same schemaId is already used for type "$test.Employee"
13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaRepository.RegisterType(Type type, String schemaId)
13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaGenerator.GenerateReferencedSchema(DataContract dataContract, SchemaRepository schemaRepository, Func`1 definitionFactory)
13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaGenerator.GenerateConcreteSchema(DataContract dataContract, SchemaRepository schemaRepository)
13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaGenerator.GenerateSchemaForType(Type modelType, SchemaRepository schemaRepository)
13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaGenerator.GenerateSchema(Type modelType, SchemaRepository schemaRepository, MemberInfo memberInfo, ParameterInfo parameterInfo)
13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaGenerator.CreateArraySchema(DataContract dataContract, SchemaRepository schemaRepository)
13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaGenerator.<>c__DisplayClass10_0.
Solution :
The only change needed is in your Startup.cs inside the method ConfigureServices.
You should add the following:
services.AddSwaggerGen(options =>
{
options.CustomSchemaIds(type => type.ToString());
});
Today I was working on a front end app. I faced below error while running npm install command.
npm ERR! Conflicting peer dependency: @angular/core@6.1.10
npm ERR! node_modules/@angular/core
npm ERR! peer @angular/core@"^6.0.3" from @angular-redux/router@9.0.0
npm ERR! node_modules/@angular-redux/router
npm ERR! @angular-redux/router@"^9.0.0" from the root project
Fix for Conflicting peer dependency in node.js
Microservices have fundamentally changed the way server side applications are architected. Rather than a single giant monolithic codebase hosting all the business logic of your application, microservices reflect the distributed systems model, where a group of application components work together to deliver the business needs.
To avoid building a mesh of tightly coupled components, consider using asynchronous communication between microservices.
You can safely introduce changes to your API and release them fast as long as they don’t break existing callers.
It's not always possible to make backwards compatible changes. When you are making a breaking change, expose a new version of your endpoint while continuing to support older versions. Consumers can choose to use the new version at their convenience. However, having too many versions of your API can create a nightmare for those maintaining the code. Hence, have a disciplined approach to deprecate older versions by working with your clients or internally rerouting the traffic to the newer versions.
You can have the best designed microservice meeting all the checks, but with a bad design of the hosting platform it would still behave poorly. Isolate your microservice infrastructure from other components to get fault isolation and best performance. It is also important to isolate the infrastructure of the components that your microservice depends on.
While microservices give you the freedom to develop and release independently, certain standards need to be followed for cross cutting concerns so that every team doesn’t spend time creating unique solutions for these. This is very important in a distributed architecture such as microservices, where you need to be able to connect all the pieces of the puzzle to see a holistic picture. Hence, enterprise solutions are necessary for API security, log aggregation, monitoring, API documentation, secrets management, config management, distributed tracing, etc.
By following these microservices best practices, you should end up with a loosely coupled, distributed, and independent microservice system, wherein you can achieve the true benefits of a microservices architecture as listed at the beginning of this article.
